Які найкращі практики використання схем у SQL Server?

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

Ми їх використовуємо

• розділити дозволи на клієнта (наприклад, у нас є настільні програми, схеми WebGUI тощо)
• для логічного групування, наприклад (Дані та схеми постановки для наших таблиць).

Корисні та практичні спостереження повз Білу книгу, згадану Мар'яном:

• ГРАНТ на схемі: більше дозволів на об'єкт більше. Таким чином, новий Proc в схемі WebGUI автоматично має дозволи схеми
• Приємні угруповання в SSMS Object Explorer
• OBJECT_SCHEMA_NAME
• Ви змушені кваліфікувати назви об'єктів (що є найкращою практикою)

Я думаю, що відповідь можна знайти в цій статті MSDN: Найкращі практики SQL Server - реалізація об'єктних схем бази даних .

Цитата: "У цій білій книзі розглядаються можливості вдосконалення адміністрування безпеки користувальницької бази даних, а також викладені деякі найкращі практики щодо використання схем для управління об'єктами баз даних у базах розробок і виробництв. Зокрема, в ній розглянуто три реальні сценарії:

• Захист об'єктів бази даних від змін користувачів без відома власника бази даних
• Запобігання базовим об'єктам баз даних, зокрема базам даних незалежних постачальників програмного забезпечення (ISV), від спеціальних або неправильних доступу користувачів, що призводять до низької продуктивності програми
• Об’єднання пов'язаних груп об'єктів (логічних об'єктів) разом у межах однієї фізичної бази даних, щоб зменшити адміністративні накладні витрати фізичної бази даних ".

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

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