Як використання окремих схем впливає на продуктивність SQL Server 2008?

Я хочу використовувати окремі схеми для об’єктів з різною метою в нашій базі даних SQL Server 2008. Зараз ми використовуємо досить розумну конвенцію іменування для позначення мети таблиці або збереженої процедури, а префікси означають, що ми повинні сканувати п'ять-шість xharacters, перш ніж ми навіть побачимо початок унікального імені. Я хотів би використовувати окремі схеми для таблиць, які просто використовуються для керування користувальницьким інтерфейсом (меню, ролі за особою тощо), а також для тих, що є розмірними таблицями проти таблиць фактів тощо.

Моє запитання полягає в тому, чи будуть впливати на ефективність використання декількох схем (схем?) Проти старого хорошого ДБО для всього?

Це може вплинути на продуктивність оптимізатора запитів, хоча і невеликий, залежно від вашого стилю кодування. Якщо ви посилаєтесь на таблицю без схеми, оптимізатор повинен спробувати визначити таблицю спочатку, перевіривши таблиці в межах схеми за замовчуванням користувачів (якщо така є), потім використовуючи dbo., А потім все інше. Якщо ви чітко посилаєтесь на таблиці як schema.table, що, мабуть, є хорошою практикою в будь-якому випадку, то навіть цього незначного накладного покриття ви будете уникати.

Немає різниці у продуктивності. Однак ви зараз використовуєте схеми (навіть якщо ви цього не знаєте).

Використання посилань на схеми об'єкти , такі як таблиці, збережені процедури, призначені для користувача функції і т.д., які НЕ схеми кваліфікованих дійсно має вплив на продуктивність. Посилання завжди повинні кваліфікуватися за схемою. Такі некваліфіковані посилання мають бути вирішені, і це відбувається так:

• По-перше, шукайте однойменний об’єкт та тип за схемою за замовчуванням у користувача, під обліковими записами якого встановлено сеанс (наприклад jsmith). Якщо його знайдено, використовується цей екземпляр.
• В іншому випадку шукайте однойменний об’єкт та тип за схемою dbo.

Це має кілька наслідків:

• Більшу частину часу потрібні два пошуку, щоб вирішити посилання, а не один пошук, необхідний, якщо посилання має схему.
• План виконання, отриманий під час прив'язки запиту / збереженої процедури / визначеної користувачем функції, не може кешуватися та використовувати повторно.

Остаточний ефект, який ви виявите - болісно - коли щось порушиться, полягає в тому, що різні користувачі можуть отримати різні результати від заданого запиту або збереженої процедури. Щось подібне select * from foo join barможе спрацювати нормально для мене як власника db; це може бути зламано для користувача, jsmithякий ненавмисно чи ні, створив таблицю, названу fooза його власною схемою ( jsmith.foo) у тій самій базі даних.

З цієї причини також createі dropзаяви повинні схематично визначати ім'я створюваного або відкинутого об'єкта.