Зачем использовать схемы базы данных?

Ответ 1

У вас есть основное преимущество с точки зрения логических объектов группировок и разрешения на установку на уровне схемы.

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

Я бы не сказал, что это было обычным делом, но большинство людей все еще бросают все в схеме dbo.

Ответ 2

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

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

Обновление через 10 лет!

Есть еще одна причина, на самом деле. Вы можете иметь "копии" вашей схемы для разных целей. Например, представьте, что вы создаете блог-платформу. Люди могут зарегистрироваться и создавать свои собственные блоги. Каждому блогу нужна таблица для сообщений, тегов, изображений, настроек и т.д. Один из способов сделать это - добавить столбец blog_id к каждой таблице и используйте это, чтобы различать блоги. Или... вы можете создать новую схему для каждого блога и новые таблицы для каждой из них. Это имеет несколько преимуществ:

• Программирование проще. Вы просто выбираете подходящую схему в начале, а затем пишете все свои запросы, не беспокоясь о том, чтобы забыть добавить куда-нибудь where [email protected].
• Вы избегаете целого класса потенциальных ошибок, когда внешний ключ в одном блоге указывает на объект в другом блоге (случайное раскрытие данных!)
• Если вы хотите стереть блог, вы просто отбрасываете схему со всеми таблицами в ней. Гораздо быстрее, чем поиск и удаление записей из десятков разных таблиц (в правильном порядке, тем не менее!)
• Эффективность каждого блога зависит только (во всяком случае, в большинстве случаев) от объема данных в этом блоге.
• Экспортировать данные проще - просто сбросьте все объекты в схеме.

Конечно, есть и недостатки.

• Когда вы обновляете свою платформу и хотите внести изменения в схему, вам нужно обновить каждый блог отдельно.
• То же самое касается исправления поврежденных данных, если это происходит по какой-либо причине.
• Статистику для всей платформы сложнее вычислить

В общем, это довольно нишевый вариант использования, но это может быть удобно!

Ответ 3

Для меня они могут вызвать больше проблем, потому что они нарушают цепочку прав собственности.

Пример:

Хранимая процедура tom.uspFoo легко использует таблицу tom.bar, но дополнительные функции необходимы для dick.AnotherTable. Это означает, что я должен предоставить права выбора на dick.AnotherTable вызывающим абонентам tom.uspFoo..., которые предоставляют прямой доступ к таблице.

Если я ничего не потеряю...

Изменить, февраль 2012

Я задал вопрос об этом: SQL Server: как разрешить схемы?

Ключ "тот же владелец": поэтому, если dbo владеет как схемой dick, так и tom, тогда применяется цепочка привязки . Мой предыдущий ответ был неправильным.

Ответ 4

Это может быть несколько причин, почему это выгодно:

• Обмен данными между несколькими (экземплярами ) приложения. Это может быть если у вас есть группа ссылок данные, которые приложений и группы данных это специфично для экземпляра. Будьте осторожны, чтобы не иметь круговых ссылок между объектами в разных схемах. Значение не имеет внешнего ключа от объекта в схеме 1 к другому объекту в схеме 2 И имеет другой внешний ключ из схемы 2 в схему 1 в других объектах.

• разделение данных: позволяет хранить данные на разных серверах более легко.

• как вы упомянули, контроль доступа на уровне DB