По умолчанию объекты (таблицы, хранимые процедуры и т.д.) настроены вместе с владельцем/схемой dbo (я думаю, что ms sql 2000 называет его владельцем, а ms sql 2005 вызывает его схему)
Владелец/схема действительно является ролью или пользователем в базе данных. Я всегда оставлял дефолт dbo, но недавно я видел несколько примеров в учебниках по подготовке к Microsoft, где некоторые из их таблиц и хранимых процедур имели разные владельцы/схемы. Когда это выгодно для этого и почему?
Использование схем исключительно полезно при возникновении проблем с безопасностью.
Если у вас есть несколько приложений, которые обращаются к базе данных, возможно, вы не захотите предоставить отделу логистики доступ к записям персонала. Таким образом, вы помещаете все ваши таблицы человеческих ресурсов в hr-схему и разрешаете доступ к ней для пользователей в роли 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 на всех наших машинах dev (назад, когда у нас была централизованная база данных разработки ранее в моей карьере).
Организация
В среде dev производственная копия объектов является dbo, но разработчики могут разрабатывать в своих собственных схемах. Тогда код может очень просто ссылаться на копию или их изменения. Использование псевдонимов может сделать эту технику еще более простой.
Кроме того, производственная база данных может поддерживать множество систем или подсистем. Вы можете использовать различные схемы, чтобы сгруппировать эти объекты.
Эта статья хорошо объясняет это, включая изменения с SQL Server 2000 по 2005 год.