Схемы T-SQL для организации кода

Question

У меня есть база данных ms sql server с растущим числом хранимых процедур и пользовательских функций, и я вижу, что некоторые должны лучше организовать код. Моя идея состояла в том, чтобы разделить sps и функции по нескольким схемам. Схема по умолчанию будет содержать sps, вызываемые извне. API базы данных другими словами. Вторая схема будет содержать внутренний код, который не должен вызываться извне. Я бы, вероятно, сделал бы то же самое для таблиц: некоторые содержат «сырые» данные, другие содержат предварительно рассчитанные данные для оптимизации, ...

Поскольку я никогда не использовал схему, у меня есть несколько вопросов:

• Имеет ли это смысл?
• Есть ли какие-либо последствия, о которых я не знаю? Например, проблемы с производительностью, когда sp в схеме A использует таблицу в схеме X?
• Можно ли ограничить "внешний мир" использованием только sp в определенной схеме? Например: пользователю A разрешено вызывать объекты только в схеме A, но sp-объектам в схеме A все еще разрешено использовать таблицы в схеме B?

Поскольку этот вопрос несколько субъективен, я отметил его как "сообщество вики". Надеюсь, что все в порядке.

Answer 1

• да, это имеет смысл

• без разницы в производительности, если все схемы имеют одного владельца (цепочка владения)

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

Мы используем схемы для разделения данных, внутренних SP, внутренних функций и затем SP для каждого клиента.

Одним из преимуществ является то, что мы ПРЕДОСТАВЛЯЕМ разрешения на схему, а не на объекты, что мне лично и нужно было уточнить в моем вопросе , прежде чем мы начали их использовать.