Медлительность при индексированном представлении для SQL 2005

Если вы не используете ни версию Enterprise, ни версию Developer, вам нужно использовать подсказку with (noexpand):

select * 
from vw_myView with (noexpand)
where companyID = 1

Когда базовые данные изменяются, представление будет обновлять только строки, связанные с измененными данными, а не всю таблицу. Это может отрицательно сказаться на базе данных OLTP с высокой степенью вставок, но при умеренном использовании не должно вызывать проблем с производительностью.

совет от Microsoft:

Как правило, любые модификации или обновления представления или базовых таблиц, лежащих в основе представления, следует по возможности выполнять пакетами, а не отдельными операциями. Это может снизить некоторые накладные расходы на обслуживание представления.

Я думаю, что вы на правильном пути с использованием представления индекса. Однако поместили ли вы индексы в таблицу, из которой вы запрашиваете, TimeCard для ваших совокупных столбцов. Вам нужно сделать индекс JobID, ProjectID, entryDate, CompanyID (1 индекс). Если вы используете 1 индекс для каждого столбца, это НЕ решит ваши проблемы, потому что Query должен будет использовать все 4 индекса вместе.

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

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

Я не думаю, что вам нужно индексированное представление (я не говорю, что индексированное представление — плохая/хорошая идея). Я думаю, вам нужен индекс по столбцам "CompanyID" и "EntryDate". После этого вы должны использовать условие where «ГДЕ CompanyID = @CompanyID AND EntryDate >= @StartDate AND EntryDate ‹= @EndDate».

Если таблица обрабатывается преимущественно с помощью «EntryDate», вы можете использовать индекс кластера в столбце «EntryDate».

После этого я думаю, что оператор select будет работать намного быстрее, чем сейчас.

Вы рассматривали возможность разбиения таблицы. Вы можете придумать комбинацию списка и хеш-таблицы разделов.

Что ж, идея с индексированным представлением определенно хороша, а если на нем можно создать кластеризованный индекс — отлично. Это должно быть быстро - гораздо лучше, чем 3 минуты на запрос!

С другой стороны: если эти фрагменты информации только когда-либо обновляются, например. раз в месяц или раз в неделю (или даже каждую ночь), может быть лучше просто поместить их в отдельную таблицу DailyTimeCard, которая заполняется/обновляется, например. пакет SSIS регулярно.

Я бы также не рекомендовал использовать триггеры для постоянного обновления такой таблицы фактов — если вам действительно очень нужны самые последние данные в каждую секунду дня, тогда оставайтесь с индексированным представлением. .

Но ваше индексированное представление выполняет довольно тяжелую работу — суммирует, группирует и так далее. Поддержание ее в актуальном состоянии все время, пока ваша базовая таблица TimeCard изменяется и обновляется, вызовет некоторую нагрузку на вашу систему - трудно сказать, насколько сильно, но это может быть весьма заметно.

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

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