Что такое схемы SQL Server?

Question

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

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

EDIT: Чтобы уточнить, я предполагаю, что я ищу преимущества схем. Если вы только собираетесь использовать его в качестве схемы безопасности, похоже, что роли базы данных уже заполнены, то .. er .. um .. role. И использование его как спецификатора пространства имен, похоже, было чем-то, что вы могли бы сделать с правами собственности (dbo против пользователя и т. Д.).

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

Answer 1

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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

Answer 8

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

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

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

Answer 9

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

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

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

Answer 10

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

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

Answer 11

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

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