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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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