Что хорошего в схемах SQL Server?

Я не новичок в использовании баз данных SQL, и в частности SQL Server. Тем не менее, я был в первую очередь парнем из SQL 2000, и меня всегда смущали схемы в 2005+. Да, я знаю базовое определение схемы, но для чего они используются в типичном развертывании SQL Server?

Я всегда просто использовал схему по умолчанию. Зачем мне создавать специализированные схемы? Зачем мне назначать какие-либо из встроенных схем?

РЕДАКТИРОВАТЬ: Чтобы уточнить, я думаю, я ищу преимущества схем. Если вы собираетесь использовать его только в качестве схемы безопасности, похоже, что роли базы данных уже заполнили эту ... э ... эээ ... роль. И использование его как спецификатора пространства имен, похоже, было чем-то, что вы могли бы сделать с владельцем (dbo против пользователя и т. Д.).

Я думаю, что я понимаю, что делают схемы, чего нельзя делать с владельцами и ролями? Каковы их конкретные преимущества?

Схемы логически группируют таблицы, процедуры, представления вместе. Все связанные с сотрудником объекты в employeeсхеме и т. Д.

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

Так же, как пространство имен кодов C #.

Они также могут обеспечить своего рода защиту от коллизий имен для данных плагинов. Например, новая функция захвата данных изменений в SQL Server 2008 помещает используемые таблицы в отдельную схему cdc. Таким образом, им не нужно беспокоиться о конфликте имен между таблицей CDC и реальной таблицей, используемой в базе данных, и в этом отношении могут сознательно скрывать имена реальных таблиц.

Я знаю, что это старая ветка, но я сам изучил схемы и думаю, что следующее может быть еще одним хорошим кандидатом для использования схемы:

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

Если вы сохраняете свою схему дискретной, вы можете масштабировать приложение, развернув данную схему на новом сервере БД. (Это предполагает, что у вас есть приложение или система, которая достаточно велика, чтобы иметь различную функциональность).

В качестве примера рассмотрим систему, которая выполняет ведение журнала. Все таблицы журналов и SP находятся в схеме [logging]. Ведение журнала является хорошим примером, поскольку редко (если вообще когда-либо) другие функциональные возможности системы перекрывают (то есть присоединяются) объекты в схеме ведения журнала.

Подсказка для использования этого метода - иметь разные строки подключения для каждой схемы в вашем приложении / системе. Затем вы развертываете элементы схемы на новом сервере и изменяете строку подключения, когда вам нужно масштабировать.

Я склонен согласиться с Брентом по этому вопросу ... см. Эту дискуссию здесь. http://www.brentozar.com/archive/2010/05/why-use-schemas/

Короче говоря ... схемы не очень полезны, за исключением очень конкретных случаев использования. Делает вещи грязными. Не используйте их, если можете помочь. И попробуйте подчиниться правилу K (eep) I (t) S (Imple) S (тупой).

Я не вижу преимущества в навязывании пользователей, привязанных к схемам. Вот почему ....

Большинство людей изначально подключают свои учетные записи пользователей к базам данных через роли. Как только вы назначаете пользователя либо системному администратору, либо роли базы данных db_owner, в любой форме эта учетная запись либо связывается с учетной записью пользователя "dbo", либо имеет полную разрешения на базу данных. Как только это происходит, независимо от того, как вы назначаете себя для схемы, выходящей за пределы схемы по умолчанию (которая имеет то же имя, что и ваша учетная запись пользователя), эти права dbo назначаются тем объектам, которые вы создаете под своим пользователем и схемой. Это своего рода бессмысленно ..... и просто пространство имен и сбивает с толку истинную собственность на эти объекты. Его плохой дизайн, если вы спросите меня .... кто бы это ни придумал.

То, что они должны были сделать, - это создать «Группы», выбросить схемы и роли и просто позволить вам распределять группы по группам в любой комбинации, которая вам нравится, а затем на каждом уровне сообщать системе, наследуются ли разрешения, отклоняются или перезаписываются пользовательскими. из них. Это было бы намного более интуитивно понятно и позволило бы администраторам баз данных лучше контролировать, кто настоящие владельцы этих объектов. Прямо сейчас в большинстве случаев подразумевается, что пользователь SQL Server по умолчанию dbo обладает этими правами ... а не пользователь.

В магазине ORACLE, в котором я работал много лет, схемы использовались для инкапсуляции процедур (и пакетов), которые применялись к различным интерфейсным приложениям. Различная схема «API» для каждого приложения часто имела смысл, поскольку варианты использования, пользователи и системные требования были совершенно разными. Например, одна схема «API» предназначалась для приложения разработки / конфигурации, которое использовалось только разработчиками. Другая схема «API» была предназначена для доступа к данным клиента через представления и процедуры (поиски). Другая схема «API» инкапсулировала код, который использовался для синхронизации разработки / конфигурации и данных клиента с приложением, имеющим собственную базу данных. Некоторые из этих схем «API» под прикрытием будут по-прежнему совместно использовать общие процедуры и функции друг с другом (через другие «ОБЩИЕ»).

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

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

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

Проблема может заключаться в том, что, если она есть, некоторые разработчики начнут использовать ее для краткосрочной выгоды; и как только он окажется там, он может стать кудзу.

В SQL Server 2000 созданные объекты были связаны с этим конкретным пользователем, например, если пользователь, скажем, Сэм создает объект, скажем, «Сотрудники», эта таблица будет выглядеть так: Sam.Employees. А что, если Сэм покидает компанию или переезжает в другой бизнес-сектор? Как только вы удалите пользователя Sam, что будет с таблицей Sam.Employees? Возможно, вам придется сначала сменить владельца с Sam.Employees на dbo.Employess. Схема предоставляет решение для преодоления этой проблемы. Сэм может создать все свои объекты в схеме, такой как Emp_Schema. Теперь, если он создает объект Employees в Emp_Schema, то этот объект будет называться Emp_Schema.Employees. Даже если учетная запись пользователя Sam должна быть удалена, схема не будет затронута.

разработка - каждый из наших разработчиков получает свою собственную схему в качестве песочницы для игры.

Вот хороший пример реализации схем с SQL Server. У нас было несколько приложений ms-access. Мы хотели преобразовать их в портал приложений ASP.NET. Каждое приложение ms-access написано как приложение для этого портала. Каждое приложение ms-access имеет свои собственные таблицы базы данных. Некоторые из них связаны, мы помещаем их в общую схему dbo SQL Server. Остальные получают свои собственные схемы. Таким образом, если мы хотим знать, какие таблицы принадлежат приложению на портале приложений ASP.NET, с которым можно легко перемещаться, визуализировать и поддерживать.