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

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

Какие практические вещи я должен учитывать при выборе между этими двумя подходами? Если я буду избегать dbo.mytableв пользу того, myschema.mytableбуду ли я создавать другие проблемы ( или проблемы ) для моей архитектуры?

Как примечание ... В какой-то момент это будет передано настоящему администратору базы данных для поддержки / поддержки, поэтому я стараюсь не усложнять им жизнь.

Начну с того, что не рассматривайте схемы как пространства имен или доменные объекты в смысле ОО. Схемы по сути являются контейнерами разрешений с некоторой добавленной стоимостью (см. Ниже)

Кроме того, «отдельные схемы» или «отдельные базы данных» - это 2 разных понятия. Данные, которые должны быть согласованными по транзакциям и ссылкам, должны находиться в одной базе данных. Видите одну базу данных или десять? статья в блоге для большего.

В этой базе данных вы можете или не можете использовать схемы для организации ваших объектов.

Лично я фанат схем и всегда использую их, но для таких вещей, как разрешения и логическая группировка. Для этого я отсылаю вас к предыдущим вопросам, где вы можете увидеть общее мнение в их пользу:

• Схема проектирования - лучшие практики?
• Каким стандартам я должен следовать при именовании таблиц и представлений?
• За использование / правильное использование схем?

Для случая для отдельных баз данных, см . Ответ Аарона , но все это зависит от «согласованного с точки зрения транзакций» требования.

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

1. Подключить ваше приложение к контекстно-зависимой базе данных и затем выполнить те же запросы гораздо проще, чем вводить запросы <schema>перед всеми ссылками на объекты. Это поддается либо динамическому SQL, либо множеству разных входов в приложение со схемами по умолчанию (то есть ваш код не будет использовать префикс схемы, полагаясь на схему по умолчанию пользователя приложения - может привести к огромному разрастанию кэша плана и трудной отладке), или много хранимых процедур для управления (представьте себе простой отчет, если вам нужна одна схема на схему, то код меняется, теперь вам нужно изменить один и тот же код несколько раз, по одному для каждой схемы).
2. Разделение на базы данных позволяет гибко перемещать занятые базы данных в более быстрые или другие хранилища / экземпляры, не вырывая объекты из одной большой всеобъемлющей базы данных. Большинство людей не думают об этом так далеко заранее, но это определенно потенциальная проблема масштаба. Особенно, если у вас одна схема, которая «берет верх» и требует большей части ресурсов на сервере, разделение их может быть чрезвычайно трудоемкой задачей, даже если они уже разделены схемой.
3. Отдельные базы данных также могут позволить вам иметь разные графики обслуживания и резервного копирования для каждого подразделения. Я не уверен, что вы подразумеваете под «делением по штатам», но если вы подразумеваете изоляцию клиентов, у вас могут быть клиенты с разными требованиями и с разным допуском к потере данных, обслуживанию индекса и т. Д.
4. У вас могут оказаться клиенты, которым по закону или корпоративной политике необходимо , чтобы вы хранили свои данные отдельно от других. Обычно это приемлемо на уровне базы данных, но уровень схемы обычно будет недостаточным. Возможно, у вас нет этих клиентов сейчас, но это может стать реальной проблемой позже, если вы это сделаете.