Запрос по сравнению сПосмотреть

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

Empasis на силе и немного...

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

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

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

Если бы Вы подразумеваете, что производительность сети, затем работающая от локального кэша (как с ADO.Net DataSets), уменьшила бы сетевой трафик - но могла вызвать проблемы с блокировкой. Просто мысль.

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

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

Однажды на давным-давно, я столкнулся с системой, где генератор запроса создал один запрос, который перечислил семнадцать таблиц на сингле ИЗ пункта, включая несколько ОСТАВЛЕННЫХ ВНЕШНИХ ОБЪЕДИНЕНИЙ таблицы с собой. И на самом деле более близкое исследование показало, что несколько из 'таблиц' были на самом деле мультитабличными представлениями, и некоторые из них также включенных сам внешние объединения, и были самостоятельно вовлечены в сам внешние объединения представления. Сказать "ужасный" - преуменьшение. Было много очистки, возможной улучшать производительность того запроса - устранение ненужных внешних объединений, сам соединения, и так далее. (Это на самом деле предшествовало явной нотации соединения SQL-92 - я сказал давным-давно - таким образом, синтаксис внешнего объединения был определенным для DBMS.)

Я не могу говорить за все базы данных, но в SQL Server Вы не можете индексировать представления, если у Вас нет Версии для предприятия. Неиндексируемое представление может быть значительно более плохим с точки зрения производительности, чем запрос особенно, если Вы пишете запрос против него для добавления некоторых где условия. Индексные представления обычно могут работать довольно хорошо. Индексное представление может также быть против нескольких полей, которые находятся в differnt таблицах, и это может улучшить производительность по специальному запросу. (Это может не также в настройке производительности, необходимо всегда тестировать против конкретных обстоятельств.)

Одна точка против представлений - то, что они не допускают выбор во время выполнения где критерии. Так часто Вы заканчиваете и с представлением и с запросом.

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

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

Существуют также ограничения на тип запросов, которые могут быть сделаны для недостатка представления специальный запрос или сохраненный proc. Например, Вы не можете использовать, если оператор (или другой процедурный код типа, такой как цикличное выполнение) или, как отмечено выше Вас не может обеспечить значения во время выполнения для где критерии.

Одно место, где представления часто значительно медленнее, - когда они называют другие представления. Базовые представления должны быть полностью поняты в некоторых базах данных, и таким образом Вам, возможно, понадобились бы к привлечению 4 459 203 записи для наблюдения 10, которыми Вы в конечном счете интересуетесь. Начните разделять это на уровни несколько раз, и это может стать очень медленным, очень быстро; представления, что представления вызова являются просто плохой практикой.

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