ПРЕДСТАВЛЕНИЯ PostgreSQL создаются недавно каждый раз, когда они запрашиваются против?
Я создаю веб-приложение, которое имеет некоторые сложные базовые ассоциации. Для решения нескольких проблем, которые я имел, я создал Представление ОБЪЕДИНЕНИЯ. Существует, вероятно, много других способов, которыми это могло быть решено.
Но я теперь рассматриваю эффективность своего дизайна, и я хотел знать, создается ли ПРЕДСТАВЛЕНИЕ недавно каждый раз, когда это запрашивается или является этим только созданный однажды и державший в курсе.
Для разработки, если я имею table_a (100 записей) и table_b (100 записей) и делаю Представление ОБЪЕДИНЕНИЯ, затем я создал представление с 200 записями.
Этот целый процесс происходит каждый раз, когда я делаю выбор против Представления?
Снова, очевидно, каждый раз, когда я обновляю записи базовой таблицы, представление обновляется, но представление обновляет эту запись, или это воссоздает целое представление с нуля?
Долина
3 ответа
Представление - это не более чем запрос с именем. Существуют возможные оптимизации, связанные с perf, которые некоторые СУБД реализуют лучше, чем другие (pgSQL, кажется, на лучшей стороне), такие как повторное использование плана запроса, кэшированный контроль доступа и т.д.
Однако, в конце концов, почти всегда можно ожидать, что представление будет вести себя так же, как и прямой запрос SQL. С той разницей, что вы можете предоставить доступ к этому запросу, не предоставляя доступ к базовым таблицам.
Существуют оптимизации, которые можно сделать, чтобы изменить поведение (сделать их наполовину похожими на таблицы), и которые могут существовать или не существовать в pgSQL, например, материализованные представления (извините, не имею представления о pgSQL), но это просто придирки.
Выполняется ли весь этот процесс каждый раз, когда я делаю выбор для представления?
Да.
Нематериализованное представление (PostgreSQL не поддерживает материализованные представления) - это просто подготовленный оператор SQL - вы получите ту же производительность, заменив ссылку на представление подзапросом, содержащим SELECT, на котором основано представление.
Вот почему значения, основанные на вспомогательных таблицах, появляются каждый раз, когда вы запускаете запрос к представлению, мне неясно, отображаются ли в PostgreSQL манипуляции с столбцами без обновления представления - IE: если вы создаете представление на основе ВЫБЕРИТЕ * FROM table_x, а затем добавьте или удалите столбец из table_x - большинству баз данных потребуется обновить представление, чтобы увидеть это изменение через представление.
Не рекомендуется создавать представления поверх представлений - они хрупкие; вы не узнаете, пока не запустите представление, зависящее от другого, если возникнет проблема. И прироста производительности нет - скорее наоборот. Повторное использование кода плохо работает в среде на основе SET ...
Используйте EXPLAIN, чтобы увидеть, как выполняется VIEW, вы увидите те же результаты, что и обычный запрос.
EXPLAIN
SELECT * FROM name_of_your_view WHERE foo = 23;
PostgreSQL будет пытаться оптимизировать внутренний запрос, даже когда вы присоединяетесь к представлениям, имеете представления, использующие другие представления, и т. Д. Старайтесь избегать ситуаций, когда VIEW должен быть выполнен до того, как оптимизатор сможет выполнить свою (отличную) работу. Агрегаты, ORDER BY и LIMIT являются примерами потенциальных проблем при использовании внутри вложенных представлений. Просто используйте EXPLAIN, чтобы увидеть, что происходит.