Следует ли избегать схемы dbo?


29

Когда дело доходит до схемы dbo:

  • Лучше ли избегать использования схемы dbo при создании объектов базы данных?
  • Почему следует избегать схемы dbo или нет?
  • Какой пользователь базы данных должен владеть схемой dbo?

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

Я нашел это заявление также от Александра Кузнецова в комментариях этого блога пост :
jrara

Да, избегай этого сейчас. dba.stackexchange.com/a/4109/630 и dba.stackexchange.com/q/8511/630 и stackoverflow.com/q/6502222/27535 @JNK: к вашему сведению
gbn

Ответы:


22

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

HR.Payhist
HR.Payscale
HR.Jobdesc
IT.username
IT.useraccesslevel
ENG.jobsite
ENG.trainings

Как директор по персоналу, я могу получить доступ ко всему в HRсхеме, как ITдиректор, я могу видеть имена пользователей и уровни доступа сотрудников. EngineeringОтдел может видеть то , что участки работы активны, и т.д. Если ДБО был набор схемы для всех таблиц я бы труднее сегментера мои данные и обеспечивая роли доступа.

Я считаю, что идея SQL Server заключается в том, чтобы предложить продукт, к которому могут обращаться различные отделы. В действительности только DBA / DBDevs действительно имеют доступ к базе данных, и она обычно хранит только данные приложения.

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

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


6

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


1
100% за этот подход. Я часто оставляю «основные» таблицы в схеме dbo для простоты и начинаю добавлять при необходимости. Обычно первая отдельная схема, которую я добавляю, это «Этап» или «Подготовка», чтобы сгруппировать мои промежуточные таблицы отдельно. Другим примером будет добавление данных из внешнего источника, скажем, Twitter. Вместо префикса всех таблиц (например, TwitterAccount, TwitterStatus и т. Д.) Я создам схему «Twitter».
Робопим

5

Во всяком случае, следует избегать использования dbo, так как он используется по умолчанию для SQL Server, а также не является описательным. Как и все другие имена по умолчанию, так как оно заранее известно, это значительно облегчает жизнь хакеру (хотя, если они просто пытаются выяснить имя вашей схемы, вы, вероятно, уже обманули).

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

Например, у нас может быть система инвентаризации с базой данных. Основные таблицы могут быть в схеме inv. Если мы импортируем что-либо в базу данных, то промежуточная схема будет использоваться как часть процесса импорта. Если у нас есть системные хранимые процедуры, к которым пользователям не нужен доступ, мы помещаем их в схему sp.


1
+1 за "избежать этого, потому что это по умолчанию". Заставляет пользователей хотя бы немного подумать об этом при создании объекта.
BradC

4

До этого не было лучшей практики, потому что схемы были скрыты до SQL 2005, все было помещено в схему dbo. Группа разработчиков SQL Server продемонстрировала это как лучший метод и опубликовала статью об этом: Рекомендации по SQL Server - реализация схем объектов базы данных

Что касается вашего второго вопроса о том, кто должен владеть им: схема dbo принадлежит учетной записи пользователя dbo.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.