За использование / правильное использование схем?

Задав этот вопрос на Stackoverflow , я удивился, где то, что я сделал, является правильным / наилучшей практикой.

По сути, каждый объект, который я создаю, входит в схему с именем схемы, отражающим использование. Например, у меня есть схемы Auditи Admin(среди других).

Это в свою очередь не оставляет никаких объектов в dbo. Это нормально? Есть ли что-нибудь еще, что мне нужно сделать?

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

Даже если текущее требование не требует особой безопасности, скажем, в будущем все объекты базы данных, связанные с аудитом, должны быть защищены от роли базы данных. Если бы эти объекты были разбросаны по всей dboсхеме, вам бы пришлось явно denyразрешить отдельные объекты. Но со Auditсхемой вы делаете сингл denyи все готово.

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

Типичным шаблоном являются схемы, основанные на разрешениях, поэтому вы должны иметь WebGUIи Desktopт. Д. Для кода, чтобы все объекты имели одинаковые разрешения из схемы .

Если у вас есть четкие группы пользователей, вы можете разрешить это, но в какой-то момент у вас будут перекрывающиеся и грязные разрешения. Я склонен откладывать проверки пользователей / групп до некоторой проверки внутри кода, а не объектов разрешений: скажем, у вас есть пользователи Admin и HR Excel: все они запускают Desktopкод.

Данные обычно используются совместно, поэтому у меня есть Dataсхема, может быть, Historyили Archiveсхема.

Некоторый код не является общедоступным (например, UDF или внутренний процесс), поэтому я бы использовал Helperсхему для кода, который не должен выполняться клиентским кодом.

Наконец, схемы как Stagingили Systemили Maintenanceиногда полезны.

Хотя в dboсхеме нет пользовательских объектов , пользователю dboпринадлежат все схемы.

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

Единственное, что я бы упомянул, - это предоставление разрешений на схему, а не отдельным объектам (ваш вопрос SO ничего не говорит о разрешениях).

Я хотел бы использовать схемы для разделения базы данных в соответствии с модулями и шаблонами использования. Я нахожу, что это облегчает понимание таблиц базы данных, поэтому обслуживание становится проще. У меня были следующие типы схем в моем последнем проекте сервера sql. LT - таблицы поиска

COMMON
LT_COMMON
MODULENAME1
LT_MODULENAME1
..

Для больших модулей мы также разделили их на несколько схем. Например, персональный модуль состоит из более чем 5 модулей.

PERSONEL_COMMON
PERSONEL_FINANCE
PERSONEL_MODULE2
..
LT_PERSONEL_COMMON
LT_PERSONEL_FINANCE
LT_PERSONEL_MODULE2

Мы также включили схемы, как для других видов деятельности TEMP, MAINTANENCE. В студии управления вы можете фильтровать, используя имя схемы. Разработчик, отвечающий за MODULE1, фильтрует по имени и почти все время работает только с этими таблицами. Это позволяет разработчикам, dbas, новичкам очень легко понимать таблицы базы данных.

Лучшие практики могут быть разными для сервера sql, чем для оракула, однако, по моему опыту, чем меньше схем, тем лучше.
Мне нравится иметь схему для dba / programmer, которая имеет специальные привилегии и некоторый код для обслуживания. Все бизнес-данные должны быть в одной схеме, чтобы вы знали, где они находятся. Соглашения об именах достаточно, чтобы различать использование таблицы или хранимого кода.
Я могу видеть случай, когда у вас есть несколько бизнес-единиц из-за разных данных с небольшим перекрытием, каждое из которых имеет свою собственную схему. В противном случае все будет просто.