Плюси / мінуси використання декількох баз даних проти використання однієї бази даних

Я працював над новим проектом, який вимагає використовувати 7 баз даних, стверджуючи, що продуктивність, стабільність та оптимізація легше реалізуються.

Хоча я не згоден, у мене виникають проблеми зі збиранням добрих аргументів для використання єдиної бази даних (розділення таблиць на логічні домени).

Один з моїх аргументів поки що - це цілісність даних (я не можу використовувати зовнішні ключі між базами даних).

Які хороші плюси / мінуси для використання однієї або декількох баз даних?

[резюме поки]

Аргументи проти декількох баз даних:

• Втрата цілісності даних (неможливо використовувати зовнішні ключі над базами даних)

• Втрата відновлення цілісності

• Набирає складності (db користувачів / ролі)

• Невеликі шанси сервера / бази даних знизяться

Рішення:

• Використовуйте схеми для розділення доменів.

• POC: Використовуйте фіктивні дані, щоб довести точку в планах виконання 7/1 db

Ніяка продуктивність, стабільність та оптимізація не відповідають дійсності. У когось є вагомий аргумент чи довідкова стаття, чому це було б правдою?

Ресурси не розподіляються в базі даних: екземпляр SQL Server врівноважує ресурси, так що це не має ніякого значення

Ти програв:

• цілісність даних
• відновити цілісність (дані в DB7 будуть пізніше, ніж DB1)

Ви отримуєте складність:

• безпека (користувачі, ролі тощо) повинна бути у всіх базах даних
• у вас є деякі дані, які не вписуються в 1 базу даних гарно

Параметри:

• розділення бази даних на окремі диски можна здійснити за допомогою файлових груп
• використовувати схеми для логічного розділення даних (на основі іншої відповіді)

Якщо ви розділяєте дані за логічним доменом, ви завжди можете переглянути схеми в SQL2008 (виходячи з типового для dbo.), Але навіть це боляче і може спричинити проблеми з АБО / пані, які не очікують, що не -стандартна схема.

Мені вже доводилося збирати дані з декількох баз даних, і це боляче і далеко не високоефективно. Ви закінчуєте кешування даних або принаймні використовуєте хитрощі для підтримки швидкості.

Як тест, побудуйте 7 фіктивних баз даних. Створіть запит, який вимагає даних одночасно з усіх 7, або принаймні гарної кількості.

Тоді порівняйте плани виконання! Я думаю, ви виграєте свою справу саме там.

Вагомими причинами для створення окремих баз даних буде підтримка різних вимог щодо доступності або спрощення адміністрування. Наприклад, якщо для ваших баз даних потрібні дуже різні графіки резервного копіювання або різні моделі відновлення. Ще одна причина, якщо ви хочете запустити їх у різних примірниках.

Немає оптимізацій продуктивності для декількох баз даних, яких ви також не можете досягти за допомогою однієї бази даних. Чи можете ви дати більш детальну інформацію про те, що ви маєте на увазі під "продуктивністю, стабільністю, оптимізацією"?

Продуманий експеримент: замість того, щоб розділяти вашу базу даних на сім частин, розділіть її замість на 7000 штук. Яка ймовірність того, що несправність обладнання вплине на вашу програму? Якщо є 0,1% шансу, що якийсь конкретний сервер може загинути в певний день, чи є ваші шанси кращими чи гіршими, що на вас вплине апаратне забезпечення при збільшенні кількості машин, від яких ви залежите?

Я думаю, що важливо розділити поняття "база даних" на дві частини: схему та дані порівняно з обладнанням, яке використовується для обслуговування даних.

Порушення бази даних на декількох машинах не принесе користі з багатьох причин, пояснених іншими відповідями в цій темі.

Якщо ви збираєтеся використовувати кілька машин для надійності та підвищення продуктивності, можливо, ви можете їх структурувати так, щоб у вас був головний сервер з декількома машинами гарячого / гарячого режиму очікування, які також можна було б використовувати для розподілу запитів по всій. Таким чином, якщо будь-яка машина відчуває збій, ви втрачаєте дані, і в гіршому випадку вам доведеться перезапустити запит. Звичайно, це складніше, ніж це, але основи дійсні.

Я погоджуюся з однією БД і використовую натомість параметри файлів та схем.

Є крайні випадки, коли розбивання на кілька частин має сенс.

Конфігурація середовища середовища (розробка, тест, прода), таких як FTP-сервери, шляхи експорту файлів тощо ..., що потрібно зберігати на одному сервері та не перезаписувати під час відновлення.

Також як спосіб виділити клієнтські зміни процедури.

Але це проблеми підтримки, а не проблеми.