Схема, Владелец для объектов в MS SQL

Question

По умолчанию объекты (таблицы, хранимые процедуры и т. Д.) Настраиваются с помощью владельца / схемы dbo (я думаю, что ms sql 2000 называет его владельцем, а ms sql 2005 - его схемой)

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

Answer 1

Использование схем исключительно полезно, если у вас есть проблемы с безопасностью.

Если у вас есть несколько приложений, которые обращаются к базе данных, вы, возможно, не захотите предоставлять отделу логистики доступ к записям персонала. Таким образом, вы помещаете все свои таблицы Human Resources в схему hr и разрешаете доступ к ней только пользователям в роли hr.

Через шесть месяцев Логистике теперь нужно знать счета внутренних расходов, чтобы они могли отправлять все эти палитры синих ручек нужным людям. Затем вы можете создать хранимую процедуру, которая будет выполняться от имени пользователя, имеющего разрешение на просмотр схемы hr, а также схемы логистики. Пользователям Logistics никогда не нужно знать, что происходит в HR, и все же они все еще получают свои данные.

Вы также можете использовать схемы, предложенные cfeduke, и просто использовать их для группировки объектов в браузере объектов. Если вы делаете это, просто будьте осторожны, потому что вы можете в конечном итоге создать Person.Address и Company.Address, когда вам действительно нужен только один dbo.Address (я не сбиваю ваш пример, cfeduke, просто использую его для иллюстрации таблицы адресов могут быть одинаковыми или могут отличаться, и это YMMV).

Answer 2

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

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

Answer 3

Я использовал схемы в прошлом как пространства имен, чтобы вы могли иметь несколько сущностей с именем Address ([Person].[Address], [Company].[Address]). Преимуществом этого является визуальная организация в SQL Management Studio, вы можете получить то же самое, поместив все в одну схему и назвав таблицы с одним идентификатором (т.е. [dbo].[PersonAddress]).

Я также использовал их для разработки между разработчиками и разработчиками, прежде чем запускать SQL Server Developer Edition на всех наших машинах разработки (еще раньше, когда в моей карьере была централизованная база данных разработки).

Answer 4

Организация

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

---

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

Answer 5

Эта статья объясняет это хорошо, включая изменения с SQL Server 2000 до 2005.