SQL Server: конвенции для именования схемы
Рассмотрите сервер базы данных, задание которого сегодня состоит в том, чтобы содержать одну базу данных. Вероятно, база данных будет перемещена в будущее к другому экземпляру базы данных, который содержит несколько баз данных и схем.
Давайте притворимся, что приложение/проект называют Invoicer 2.0. Базу данных называют AcmeInvoice. База данных содержит весь счет, клиента и информацию о продукте. Вот схема агентов и их ролей и поведения.
Схема (схемы) будет в основном использоваться для легкого присвоения полномочий ролям. Дополнительное преимущество здесь - то, что объекты не находятся под dbo, и что объекты и полномочия могут быть портированы к другой машине в будущем.
Вопрос
- Какие конвенции Вы используете при именовании схемы?
- Это - хорошая форма для именования схемы тем же как базу данных?
3 ответа
Параллельное программирование с MPI Питера С. Пачеко - это хорошая вводная книга. Обратите внимание, что книга использует Си, но это должен быть простой переход к использованию привязок C++ MPI.
-121--1452238-Некоторые инструкции по началу работы можно найти на сайте LAM/MPI
-121--1452242-. Если имя схемы в конечном итоге совпадает со схемой базы данных, то вы просто добавляете избыточность в базу данных. Найдите в базе данных объекты, имеющие общую область или назначение, и создайте схему, чтобы отразить эту область. Так, например, если у вас есть сущность для счетов-фактур, и у вас есть некоторые поддерживающие таблицы поиска для состояний счетов-фактур и т.д., то поместите их все в схему счетов-фактур.
Как правило, я бы постарался избежать использования имени, которое отражает имя приложения, имя базы данных или другие конкретные/физические вещи, потому что они могут изменяться, и найти имя, которое концептуально представляет область ваших объектов, которые войдут в схему.
В комментарии указано, что «схемы будут в значительной степени использоваться для простого назначения разрешений ролям». На диаграмме показаны определенные типы пользователей, имеющие доступ к некоторым/всем таблицам или к некоторым/всем хранимым процессам. Я думаю, что попытки организовать объекты концептуально в схемы и организовать их с точки зрения безопасности в схемы являются противоречивыми вещами. Я выступаю за создание ролей в SQL Server для отражения типов пользователей и предоставление этим ролям доступа к конкретным объектам, которые необходимы каждому типу пользователя, в соответствии с предоставлением роли или доступа пользователя к схеме для построения рамки безопасности.
Почему вы назвали схему так же, как базу данных? Это означает, что все объекты базы данных подпадают под одну схему. В таком случае зачем вообще нужна схема?
Обычно схемы используются для группировки объектов в рамках общей области действия или функции. Например, учитывая то, что вы описали, у вас может быть схема счета-фактуры, схема клиента и схема продукта. Все объекты, связанные со счетом-фактурой, войдут в схему счета-фактуры, все объекты, связанные с клиентом, войдут в схему клиента, и то же самое для продуктов.
Мы также часто будем использовать общую схему, которая включает объекты, которые могут быть общими для всего нашего приложения.
Я бы назвал базу данных AcmeInvoice (или другое подходящее имя) и схему Invoicer2.
Мои причины следующие: Acmeinvoice означает, что я группирую все эти объекты / данные приложений вместе. Поэтому его можно перемещать как одно устройство на другие машины (резервное копирование / восстановление или отключение / присоединение).
Схема будет Invoicer2. Приложения меняются, возможно, в будущем у вас будет Invoicer21 (вы создадите схему) или, возможно, модуль или систему отчетов (схема отчетов). Я считаю, что использование схем позволяет мне разделять данные / процедуры в одной базе данных на разные группы, что упрощает администрирование разрешений.