Являются ли представления базы данных только средством упрощения доступа к данным или обеспечивают преимущества производительности при доступе к представлениям, а не просто выполнение запроса, на основе которого создается представление? Я подозреваю, что представления функционально эквивалентны просто добавлению сохраненного запроса к просмотру каждого запроса в данных вида, правильно ли это или существуют другие детали и/или оптимизации?
Представления базы данных влияют на производительность запросов?
Ответ 1
Хотя определенный запрос, выполняемый внутри представления и тот же запрос, который выполняется за пределами представления, должен выполняться аналогично, ситуация становится намного сложнее, когда вам нужно объединить два представления. Вы можете легко привести таблицы, которые вам не нужны в запросе, или избыточность таблиц. У оптимизатора базы данных может возникнуть больше проблем при создании хорошего плана выполнения запросов. Таким образом, хотя представления могут быть очень хорошими с точки зрения обеспечения более тонкой защиты и т.п., Они не обязательно хороши для модульности.
Ответ 2
Это зависит от СУБД, но, как правило, оптимизация не происходит, и это просто удобный способ упрощения запросов. Однако в некоторых системах баз данных используются "материализованные представления", которые используют механизм кэширования.
Ответ 3
Я всегда считал представления похожими на хранимые процедуры только для чтения. Вы даете базе данных столько информации, сколько можете заранее, чтобы она могла предварительно скомпилировать, насколько это возможно.
Вы можете индексировать представления, а также позволять вам получить доступ к оптимизированному представлению данных, которые вы используете для типа запроса, который вы используете.
Ответ 4
Обычно представление - это просто способ создать общую сокращенную форму для частого определения наборов результатов.
Однако есть недостаток. Искушение состоит в том, чтобы добавить в каждый столбец, который, по вашему мнению, может понадобиться где-нибудь, когда вы захотите использовать представление. Таким образом, YAGNI нарушается. Не только столбцы, но и иногда дополнительные внешние соединения накладываются на "на всякий случай". Таким образом, охват индексов может не охватывать больше, и план запроса может увеличиться по сложности (и снизить эффективность).
YAGNI является критическим понятием в дизайне SQL.
Ответ 5
В общем случае представления должны выполняться эквивалентно запросу, написанному непосредственно в базовых таблицах.
Но: могут быть случаи кросс, и вам следовало бы проверить ваш код. Все современные системы РСУБД имеют инструменты, которые позволят вам увидеть планы запросов и контролировать выполнение. Не принимайте мое (или чужое) слово для него, когда вы можете иметь окончательные данные под рукой.
Ответ 6
Я знаю, что это старый поток. Дискуссия хорошая, но я хочу бросить еще одну мысль. Производительность также зависит от того, что вы используете для сбора данных. Например, если вы используете интерфейс Microsoft Access, вы можете, безусловно, повысить производительность для некоторых сложных запросов, используя представление. Это связано с тем, что Access не всегда тянет с SQL-сервера, как хотелось бы - в некоторых случаях он будет тянуть целые таблицы, а затем попытаться обработать локально там! Не так, если вы используете представление.
Ответ 7
Да, во всех современных RDBMS (MSSQL после 2005? и т.д.) просмотр планов запросов кэшируется, устраняя накладные расходы на планирование запроса и ускоряя производительность по сравнению с тем же SQL, выполняемым в режиме онлайн. Ранее к этому (и это относится также к параметризованным SQL/подготовленным заявкам), люди правильно думали, что хранимые процедуры выполняются лучше.
Многие по-прежнему считают, что это современный миф БД. С тех пор, как Views/PS получили кэшированное планирование запросов SP, они были в значительной степени даже.