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


185

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

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

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

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

Ответы:


164

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

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


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

9
Не могли бы вы использовать отдельную базу данных?
Сэм Йи

7
Это разрешение схемы звучит хорошо на бумаге ... но редко когда-либо используется должным образом. Для меня это не стоит беспокойства.
Сам Йи

3
Но если это так, разве вы не можете достичь того же, используя соглашения об именах? Я не предлагаю там НЕ вариант использования для этого; чаще всего это сложение путем вычитания.
Сам Йи

6
@ Ajedi32, да ... со схемами вы можете получить один атомарный коммит в одном журнале транзакций и сделать резервную копию всех ваших данных за один раз вместо двух баз данных, которые не синхронизированы, а также для борьбы с распределенными транзакциями.
Мэтью Уайтед

31

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


16
К сожалению, однако, схемы и пространства имен .NET не очень хорошо сочетаются друг с другом с точки зрения ORM ( а именно Entity Framework ). Таблицы в MyDatabase.MySchemaсхеме магически не отображаются на классы сущностей в MyProject.MyDatabase.MySchemaпространстве имен. Стоит также отметить, что любые .хаки dot-notation ( ) в именах таблиц будут заканчиваться символами подчеркивания ( _) в именах классов. Просто пища для неудачных мыслей.
Дэн Лугг

2
Хорошая аналогия для обучения. Я не вижу, чтобы это воспринималось на 100% буквально ... (эти предостережения звучат незначительно на практике)
Саманта Бранхам

6
Лично я хотел бы, чтобы они были больше похожи на пространства имен .NET, чтобы можно было вложить произвольное количество схем ( как вы можете с пространствами имен ) для организационных целей. Это, и я бы хотел, чтобы они лучше отображались в EF.
Дэн Лугг

Они не похожи на пространства имен в любом языке, о котором я могу думать.
Танвеер Бадар

29

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


17

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

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


9

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

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

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


8

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

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


2
Я не думаю, что Брент утверждает, что «схемы плохие», просто использование схем не по умолчанию намного сложнее, чем просто использование схемы по умолчанию. Остальная часть вашего суммирования является точной.
Джозеф Дейгл

«Если [схемы используются] правильно, они позволяют вам разделять разрешения по группам объектов». ~ brentozar.com/archive/2010/05/why-use-schemas
LL Learner

7

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

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

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


7

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

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


В Oracle, поскольку 1 экземпляр = 1 база данных = 1 лицензия для оплаты, люди используют схемы shemas, чтобы избежать создания другой базы данных и оплаты другой лицензии. В SQl Server 1 сервер может обрабатывать множество баз данных.
Патрик Хонорез

5

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

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

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


3

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


1
Это больше не соответствует действительности, поскольку с 2000 года появилось две новые версии
Хоган,

0

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


29
-1 Лучше дать разработчикам отдельные целые копии базы данных для игры на их собственной машине. В противном случае они могли бы только безопасно изменить то, что находится в их схеме. Это усложняет продвижение к жизни, а также усложняет разделение схемы по другим причинам, описанным в других ответах.
Стивен Тернер,

5
Я не могу говорить о приложении, над которым вы работаете ... но ваша разработка должна максимально отражать производство. Наличие схем в dev, а не в prod может быть проблематичным.
Сам Йи

0

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.