Критерії прийняття рішення про те, коли використовувати не-dbo схему проти нової бази даних

Я в основному розробник додатків, але мені здається, що я повинен виконувати всі роботи по передній базі даних для мого поточного проекту ( btw ... його MS SQL Server 2008 ). В якості першого рішення я намагаюся розібратися, чи слід розділити свій стан за допомогою окремих баз даних або за допомогою окремих схем в одній базі даних. Я трохи прочитав схеми SQL Server Schema і, здається, це природний спосіб відокремити об’єктні домени ( що мені подобається ), але я не впевнений, чи можуть бути приховані витрати на цю модель.

Які ще практичні речі слід враховувати, обираючи між цими двома підходами? Якщо я уникаю dbo.mytableкористі, чи myschema.mytableбуду створювати інші проблеми ( або проблеми ) для своєї архітектури?

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

Почну з того, що не розглядайте схеми як простори імен чи об’єктні домени в сенсі ОО. Схеми по суті є контейнерами дозволів з деякою додатковою вартістю (див. Нижче)

Також "окремі схеми" або "окремі бази даних" - це 2 різні поняття. Дані, які повинні бути транзакційними та референтно узгодженими, повинні бути в одній базі даних. Дивіться одну базу даних або десять? стаття в блозі для отримання додаткової інформації.

У цій базі даних ви можете або не можете використовувати схеми для організації своїх об'єктів.

Особисто я прихильник схем і завжди використовую їх, але для таких речей, як дозволи та логічне групування. Для цього я посилаюсь на попередні питання, де ви бачите, що загальна думка їм на користь:

• Дизайн схеми - найкращі практики?
• Якого стандарту слід дотримуватися, називаючи таблиці та представлення?
• Над використанням / правильним використанням схем?

Що стосується окремих баз даних, дивіться відповідь Аарона , але це все залежить від вимоги "транзакційно та референтно послідовно".

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

1. Підключення програми до бази даних, що залежить від контексту, а потім виконання тих же запитів набагато простіше, ніж введення запитів <schema>перед усіма посиланнями на об'єкти. Це піддається або безлічі динамічних SQL, безлічі різних входів додатків із схемами за замовчуванням (тобто ваш код не використовував би префікс схеми, покладаючись на схему за замовчуванням користувача додатка - це може призвести до масивного розриву кешу плану та важкої налагодження), або багато збережених процедур для управління (зображуйте просто простий звіт; якщо вам потрібен один на схему, то код змінюється, тепер вам доведеться кілька разів змінювати один і той же код по одній схемі).
2. Відокремлення по базі даних дозволяє вам переміщувати зайняті бази даних до більш швидкого або іншого сховища / екземплярів, не виймаючи об'єкти з однієї великої всеохоплюючої бази даних. Більшість людей не думають про це настільки заздалегідь, але це, безумовно, потенційна проблема масштабу. Особливо, якщо у вас є одна схема, яка "переймає" і вимагає більшості ресурсів на сервері, їх розділення може бути надзвичайно громіздким завданням, навіть якщо вони вже розділені схемою.
3. Окремі бази даних також дозволяють мати різні графіки обслуговування та резервного копіювання для кожного підрозділу. Я не впевнений, що ви маєте на увазі під "поділити за державою", але якщо припустити, що ви маєте на увазі ізоляцію клієнтів, у вас можуть бути клієнти з різними вимогами та різною толерантністю до втрати даних, обслуговування індексу тощо.
4. Ви можете виявитись клієнтами, яким за законом або за корпоративною політикою потрібно зберігати їх дані окремо від інших. Зазвичай це прийнятно на рівні бази даних, але рівень схем, як правило, буде недостатнім. У вас, можливо, зараз немає цих клієнтів, але згодом це може стати справжньою проблемою.