Каковы некоторые рекомендации по использованию схем в SQL Server?

Я понимаю возможности схем SQL Server, но каковы лучшие практики? Конечно, они обеспечивают еще один уровень безопасности и обеспечивают логическое группирование объектов базы данных в базе данных, но что там типичного? Я часто, по моему опыту, не вижу много пользовательских схем, используемых. Это типично? Является ли это редким сценарием, когда следует использовать пользовательские схемы?

Мы используем их

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

Полезные и практические наблюдения за белой книгой, упомянутой Марианом:

• GRANT для схемы: нет больше разрешений для объекта. Таким образом, новый процесс в схеме WebGUI автоматически получает разрешения для схемы
• Хорошие группировки в SSMS Object Explorer
• OBJECT_SCHEMA_NAME
• Вы вынуждены квалифицировать имена объектов (что является наилучшей практикой)

Я думаю, что ответ можно найти в этой статье MSDN: Рекомендации по SQL Server - реализация схем объектов базы данных .

Цитата: «В этом техническом документе обсуждаются возможности для улучшения администрирования безопасности пользовательской базы данных, а также приводятся некоторые рекомендации по использованию схем для управления объектами базы данных в базах данных разработки и эксплуатации. В частности, рассматриваются три реальных сценария:

• Защита объектов базы данных от изменения пользователями без ведома владельца базы данных
• Предотвращение базовых объектов базы данных, в частности, баз данных независимых поставщиков программного обеспечения, от специального или неправильного доступа пользователей, что ведет к снижению производительности приложений
• Объединение связанных групп объектов (логических объектов) в одну физическую базу данных для снижения административных издержек физической базы данных ».

Я особенно использую третью часть - связать группу объектов вместе на основе их логического значения - разные схемы, принадлежащие разным проектам в одной базе данных.

Вы можете обратиться к некоторым основополагающим текстам по этому вопросу, чтобы ответить на некоторые ваши вопросы. Документы по модели реляционной базы данных от EF Codd и CJ Date касаются многих общих вопросов, связанных с дизайном, производительностью, безопасностью, оптимальным дизайном схемы и т. Д. В конечном счете, как отцы современной модели реляционной базы данных, их работы лежат в основе DB2, ORACLE, SQL Server (Microsoft и Sybase), Ingres, MySQL и любой другой доступный набор решений для реляционных баз данных.