SQL Server: соглашения по именованию схемы

Question

Рассмотрим сервер баз данных, задачей которого сегодня является размещение одной базы данных. Вероятно, в будущем база данных будет перемещена в другой экземпляр базы данных, в котором размещены несколько баз данных и схем.

Давайте представим, что приложение / проект называется Invoicer 2.0. База данных называется AcmeInvoice. База данных содержит всю информацию о счетах, клиентах и ​​продуктах. Вот схема актеров, их ролей и поведения.

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

Вопрос

• Какие соглашения вы используете, когда называет схему?
• Хорошо ли называть схему так же, как базу данных?

Answer 1

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

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

Ваш комментарий гласит, что "схемы будут в основном использоваться для простого назначения разрешений ролям". На вашей диаграмме показаны определенные типы пользователей, имеющие доступ к некоторым / всем таблицам или некоторым / всем сохраненным процессам. Я думаю, что попытка концептуально организовать объекты в схемы и организовать их с точки зрения безопасности в схемы - противоречивые вещи. Я за создание ролей на сервере sql для отражения типов пользователей и предоставления этим ролям доступа к определенным объектам, которые нужны каждому типу пользователей, в отличие от предоставления роли или пользователю доступа к схеме для построения вашей инфраструктуры безопасности.

Answer 2

Почему вы называете схему такой же, как база данных? Это означает, что все объекты базы данных попадают под одну и ту же схему. Если это так, зачем вообще нужна схема?

Обычно схемы используются для группировки объектов в рамках общей области действия или функции. Например, учитывая то, что вы описали, у вас может быть схема Invoice, схема Customer и схема Product. Все объекты, связанные со счетами, будут включены в схему счетов, все объекты, связанные с клиентами, будут включены в схему клиентов, и то же самое для продуктов.

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

Answer 3

Я бы назвал базу данных AcmeInvoice (или другое подходящее имя) и схему Invoicer2.

Мои причины следующие: Acmeinvoice означает, что я группирую все объекты / данные приложений вместе. Поэтому его можно перемещать как одно устройство на другие машины (резервное копирование / восстановление или отсоединение / подключение).

Схема будет Invoicer2. Приложения меняются, возможно, в будущем у вас будет Invoicer21 (вы создадите схему), или, возможно, модуль или система отчетов (схема отчетов). Я считаю, что использование схем позволяет мне разделять данные / процедуры в одной базе данных на разные группы, что облегчает администрирование разрешений.