Производительность при запросе вида

Question

Мне интересно, плохо ли это, или вообще это правильный подход.

Допустим, я создал представление, которое объединяет несколько атрибутов из нескольких таблиц.

Мой вопрос, что мне нужно сделать, я могу запросить этот вид, как если бы он был таблицей, не беспокоясь о производительности?

Все атрибуты в исходных таблицах проиндексированы, я обеспокоен тем, что в представлении результата будут сотни тысяч записей, которые я хочу немного сузить на основе ввода пользователем.

То, что я хотел бы избежать, имеет несколько версий кода, который генерирует этот вид, плавающий вокруг, с несколькими дополнительными условиями «где», чтобы облегчить фильтрацию ввода пользователя.

Например, предположим, что мой вид имеет этот заголовок VIEW(Name, Type, DateEntered), это может иметь 100 000+ строк (возможно, миллионов). Я хотел бы быть в состоянии сделать это представление в SQL Server, а затем в моем приложении писать querlies так:

SELECT Name, Type, DateEntered FROM MyView WHERE DateEntered BETWEEN @date1 and @date2;

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

Answer 1

Мой вопрос, что мне нужно сделать, чтобы я мог запросить это представление, как если бы это была таблица, не беспокоясь о производительности?

SQL Server очень хорошо видно, что нет.

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

Это означает, что

CREATE VIEW myview AS 
SELECT * 
FROM /* complex joins */ 

SELECT * 
FROM mytable 
JOIN myiew 
ON  … 

и

SELECT * 
FROM mytable 
JOIN (
     SELECT * 
     FROM /* complex joins */ 
     ) myview 
ON  … 

будет иметь такую ​​же производительность.

Answer 2

Зачем это плохо? Я имею в виду, что вы можете рассматривать представление как скомпилированный оператор select. Он использует существующие индексы в базовых таблицах, даже если вы добавляете дополнительные предложения where. По-моему, это хороший подход. В любом случае это лучше, чем наличие практически одного и того же оператора выбора, разбросанного по всему вашему приложению (по крайней мере, с точки зрения дизайна и обслуживания).

Answer 3

SQL Server 2005 имеет indexed views - они предоставляют индексы на представлениях. Это должно помочь в производительности. Если базовые таблицы уже имеют хорошие индексы в запрошенных полях, они будут использоваться - вам следует добавлять только индексированные представления, если это не так.

Данные в других системах баз данных известны как materialized views.

Answer 4

Если не индексируются, то ...

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

То, что убьет вас, - это вид сверху на вид сверху, на мой взгляд.

Answer 5

Он должен, в общем, выполнять не хуже, чем встроенный код.

Обратите внимание, что можно сделать вид, который скрывает очень сложную обработку (объединяет, сворачивает, укладывает CTE и т. Д.), И вы никогда не захотите, чтобы кто-либо мог SELECT * FROM view на такое представление на все время или на все продукты или без разницы. Если у вас есть стандартные критерии фильтрации, вы можете использовать встроенную функцию, ориентированную на таблицу (эффективно параметризованное представление), что потребует от всех пользователей ожидаемых параметров.

В вашем случае, например, они всегда должны делать:

SELECT Name, Type, DateEntered 
FROM MyITVF(@date1, @date2); 

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

Answer 6

Представление будет использовать индекс в вашем предложении WHERE для фильтрации результатов.

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