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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

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

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

Answer 9

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

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

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

Answer 10

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