PostgreSQL VIEWS создается заново каждый раз, когда к ним обращаются?

Question

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

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

Для уточнения, если у меня есть table_a (100 записей) и table_b (100 записей) и я создал представление UNION, то я создал представление с 200 записями.

Происходит ли весь этот процесс каждый раз, когда я делаю выбор против просмотра?

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

Дейл

Answer 1

Представление - это не что иное, как запрос с именем. Существуют возможные оптимизации, связанные с перфорированием, которые некоторые СУБД реализуют лучше, чем другие (pgSQL, кажется, находится на лучшей стороне), такие как повторное использование плана запросов, управление кэшированным доступом и т. Д.

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

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

Answer 2

Используйте EXPLAIN, чтобы увидеть, как выполняется VIEW, вы увидите те же результаты, что и обычный запрос.

EXPLAIN
SELECT * FROM name_of_your_view WHERE foo = 23;

PostgreSQL попытается оптимизировать внутренний запрос, даже когда вы присоединяетесь к представлениям.представления с использованием других представлений и т. д. Старайтесь избегать ситуаций, когда VIEW должен быть выполнен до того, как оптимизатор сможет выполнить свою (большую) работу.Агрегаты, ORDER BY и LIMIT являются примерами потенциальных проблем при использовании внутри вложенных представлений.Просто используйте EXPLAIN, чтобы увидеть, что происходит.

Answer 3

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

Да.
Нематериализованное представление (PostgreSQL не поддерживает материализованные представления)просто подготовленный оператор SQL - вы получите ту же производительность, заменив ссылку на представление подзапросом, содержащим SELECT, на котором основано представление.

Именно поэтому значения, основанные на вспомогательных таблицах, появляются каждый раз, когда вывыполнить запрос к представлению, мне неясно, если манипуляции со столбцами становятся видимыми в PostgreSQL без обновления представления - IE: если вы создаете представление на основе SELECT * FROM table_x, а затем добавляете или удаляете столбец из table_x - чащебазы данных потребуют от вас обновить представление, чтобы увидеть это изменение через представление.

Не рекомендуется создавать представления поверх представлений - они хрупкие;вы не узнаете, пока не запустите представление, зависящее от другого, если есть проблема.И нет никакого увеличения производительности - скорее наоборот.Повторное использование кода неэффективно в среде на основе SET ...