Как использование отдельных схем влияет на производительность SQL Server 2008?

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

Мой вопрос: будет ли влияние на производительность от использования нескольких схем (schemae?) Против старого доброго dbo для всего?

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

Нет разницы в производительности. Однако вы используете схемы прямо сейчас (даже если вы этого не знаете).

Использование ссылок на объекты схемы, такие как таблицы, хранимые процедуры, пользовательские функции и т. Д., Которые не квалифицированы по схеме , оказывает влияние на производительность. Ссылки всегда должны быть квалифицированы по схеме. Такие неквалифицированные ссылки должны быть разрешены, и это происходит так:

• Сначала ищите объект с тем же именем и типом в схеме по умолчанию пользователя, под чьими учетными данными был установлен сеанс (например, jsmith). Если найден, этот экземпляр используется.
• В противном случае ищите объект с тем же именем и типом в схеме dbo.

Это имеет несколько эффектов:

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

Окончательный эффект, который вы обнаружите - только болезненно - когда что-то ломается, - это то, что разные пользователи могут получить разные результаты от данного запроса или хранимой процедуры. Нечто подобное select * from foo join barможет хорошо работать для меня как владельца БД; он может быть поврежден для пользователя, jsmithкоторый случайно или нет создал таблицу с именем fooего собственной схемы ( jsmith.foo) в той же базе данных.

По этой причине createи dropоператоры должны указывать в качестве схемы имя создаваемого или удаляемого объекта.