Каковы преимущества схем SQL Server?

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

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

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

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

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

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

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

Ответ 8

В магазине ORACLE, в котором я работал много лет, были использованы схемы для инкапсуляции процедур (и пакетов), которые применяются к различным приложениям front-end. Другая схема API для каждого приложения часто имела смысл, поскольку варианты использования, пользователи и системные требования были совершенно разными. Например, одна схема API была для приложения для разработки/настройки, которое может использоваться разработчиками. Другая схема "API" заключалась в доступе к клиентским данным через представления и процедуры (поиски). Другой инкапсулированный код схемы API, который использовался для синхронизации данных разработки/конфигурации и клиента с приложением, имеющим собственную базу данных. Некоторые из этих "API" -схем, под крышками, по-прежнему будут иметь общие процедуры и функции с eachother (через другие "COMMON" схемы), где это имеет смысл.

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

Ответ 9

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

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

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

Ответ 10

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

Ответ 11

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

Ответ 12

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