Рекомендации по использованию схем в SQL Server (2008 г.)

В базе данных AdventureWorks я вижу, что для группировки таблиц используются разные схемы. Почему это делается (безопасность, ...?) И могу ли я найти лучшие практики?

спасибо, Ливен Кардоен

Ответов (1)

Решение

Как менеджер Business Intelligence, мы полагаемся на схему для логического группирования и управления безопасностью. Вот несколько примеров того, как мы используем схему:

ЛОГИЧЕСКАЯ ОРГАНИЗАЦИЯ

  1. У нас есть общая база данных, которая загружается пакетами SSIS исключительно для промежуточных данных перед загрузкой нашего хранилища операционных данных (ODS). В этой базе данных, за исключением схемы, все объекты идентичны по структуре (имена таблиц, имена столбцов, типы данных, допустимость значений NULL и т. Д.) К их исходному источнику. Мы используем схему, чтобы указать исходную исходную систему таблицы. В некоторых редких случаях в двух разных базах данных есть таблицы с одинаковым именем, а схема позволяет нам продолжать использовать исходное имя в промежуточной базе данных.

  2. В каждой базе данных на наших серверах бизнес-аналитики каждый член команды имеет схему test_username. Когда мы создаем тестовые объекты в базе данных, это упрощает отслеживание того, кто создал объект. Это также значительно упрощает очистку тестовых объектов позже, поскольку каждый знает, кто что сделал. Честно говоря, просто зная, что мы сделали это, обычно достаточно, чтобы знать, что его можно безопасно удалить, особенно когда мы не можем вспомнить, когда и почему мы это сделали!

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

  4. В нашем хранилище данных звездообразной схемы все объекты разделены на схемы измерений и фактов.

  5. Когда мы отправляем данные на серверы других подразделений, мы заставляем все объекты бизнес-аналитики на их серверах использовать схему bi. Это позволяет ДЕЙСТВИТЕЛЬНО легко узнать, что би загружает и поддерживает таблицу, даже если ее нет на нашем сервере. Если целевой сервер не является сервером SQL Server 2008/2005, тогда мы добавляем к таблице префикс bi_.

Когда дело доходит до этого, мы используем схему для логической организации в любое время, когда мы ДОЛЖНЫ добавлять префикс или суффикс к объекту, чтобы помочь организовать его при отсутствии схемы. Сказав это, есть несколько случаев, когда мы не используем схему на наших серверах BI. В нашей WorkingDB все dbo. Наша WorkingDB используется как TempDB для создания временных таблиц, но эти таблицы являются временными таблицами, которые, как мы знаем, мы будем создавать каждый раз при запуске процесса ETL. Особое свойство WorkingDB заключается в том, что мы никогда не выполняем резервное копирование базы данных, и все процессы ETL, которые используют эту базу данных, должны иметь возможность воссоздавать свои объекты с нуля при отсутствии таблицы. В этом случае мы почувствовали, что использование схемы не добавило НИКАКОЙ организационной ценности, поскольку на самом деле мы не используем объекты вне их временного процесса ETL.

БЕЗОПАСНОСТЬ

  1. Поскольку мы являемся группой бизнес-аналитики, мы обычно не создаем и не поддерживаем собственные приложения. Мы почти исключительно используем приложения других людей и переносим данные из их внутренних баз данных на наш сервер. Однако у нас есть одна база данных под названием bi_applications, которая является серверной частью для множества небольших приложений CRUD. Эти приложения обычно представляют собой формы ввода данных, которые мы предоставляем бизнесу, чтобы они могли собирать данные, которые в противном случае нам пришлось бы поддерживать в BI. Это способ переноса данных, которые должны быть в производственных приложениях, в бизнес-аналитику, пока мы ждем, когда улучшения наших низкоприоритетных приложений соберутся в списках будущих разработок. Каждое приложение имеет отдельную схему, и учетная запись приложения, используемая для обновления базовых таблиц, имеет доступ ТОЛЬКО к объектам связанной схемы.

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

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

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