По умолчанию объекты (таблицы, хранимые процедуры и т.д.) настраиваются с помощью владельца / схемы dbo (я думаю, что ms sql 2000 называет его владельцем, а ms sql 2005 называет его схемой)
Владелец / схема на самом деле является ролью или пользователем в базе данных. Я всегда оставлял dbo по умолчанию, но недавно я видел несколько примеров в учебных пособиях Microsoft, где некоторые из их таблиц и хранимых процедур имели разных владельцев / схемы. Когда это выгодно и почему?
Использование схем исключительно полезно, когда у вас есть проблемы с безопасностью.
Если у вас есть несколько приложений, которые обращаются к базе данных, возможно, вы не захотите предоставлять отделу логистики доступ к записям отдела кадров. Таким образом, вы помещаете все свои таблицы управления персоналом в схему hr и разрешаете доступ к ней только пользователям с ролью hr.
Через шесть месяцев отдел логистики теперь должен знать счета внутренних расходов, чтобы они могли отправлять все эти палитры синих ручек нужным людям. Затем вы можете создать хранимую процедуру, которая будет выполняться от имени пользователя, имеющего разрешение на просмотр схемы кадров, а также схемы логистики. Пользователям логистики никогда не нужно знать, что происходит в HR, и при этом они все равно получают свои данные.
Вы также можете использовать схемы так, как предлагает cfeduke, и просто использовать их для группировки объектов в обозревателе объектов. Если вы делаете это, просто будьте осторожны, потому что вы можете в конечном итоге создать Person.Address и Company.Address, когда вам действительно нужен только один dbo.Address (я не стучу в ваш пример, cfeduke, просто использую его, чтобы проиллюстрировать, что оба таблицы адресов могут быть одинаковыми или могут быть разными, и это YMMV).
В SQL 2000 схемы эквивалентны пользователям базы данных, в SQL 2005 каждая схема представляет собой отдельное пространство имен, которое существует независимо от пользователя базы данных, создавшего ее.
Я использую схемы, когда мне нужно создать функции или модули, которые, возможно, будут использоваться позже в других проектах, поэтому я смогу изолировать объекты базы данных, которые используются модулем.
В прошлом я использовал схемы, похожие на пространства имен, чтобы у вас могло быть несколько объектов с именем Address ([Person].[Address], [Company].[Address]). Преимущество этого заключается в визуальной организации в SQL Management Studio, вы можете получить то же самое, поместив все в одну схему и назвав таблицы с одним идентификатором (например, [dbo].[PersonAddress]).
Я также использовал их для разработки и разработки для разработчиков перед запуском SQL Server Developer Edition на всех наших машинах для разработки (еще тогда, когда у нас была централизованная база данных для разработки в начале моей карьеры).
Организация
В среде разработки производственной копией объектов является dbo, но разработчики могут разрабатывать свои собственные схемы. Тогда код может очень просто ссылаться на копию продукта или их изменения. Использование псевдонимов может сделать этот метод еще более простым.
Кроме того, производственная база данных может поддерживать множество систем или подсистем. Вы можете использовать разные схемы, чтобы эти объекты были сгруппированы.
Эта статья хорошо это объясняет, включая изменения с SQL Server 2000 на 2005.
