Индексы

Каким образом ты собрался использовать представления для денормализации?

Строить списки на основе исходных данных, вести статистику чего-либо.

И в каком месте это *денормализация*?

И в каком месте это *денормализация*?

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

Являются ли представления медленнее, чем обычные таблицы? Хранятся ли они на диске или дёргаются каждый раз при запросе? При каких условиях они пересчитываются, если хранятся?

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

Глупости.

Глупости.

Спасибо, но вопрос был не в этом.

Спасибо, но вопрос был не в этом.

Менее тупым вопрос, однако, тоже не стал.

Строить списки на основе исходных данных

Это не «денормализация», это «представление». Фактически, представление это просто постоянно хранимый именованый запрос, и не более.

Фактически, представление это просто постоянно хранимый именованый запрос, и не более.

То есть запросы к VIEW будут (значительно) медленнее, чем запросы к обычной таблице?

и не более.

Представления могут быть индексируемыми.

Представления могут быть индексируемыми.

Они могут быть даже материализованными, для них могу быть созданы триггеры позволяющие делать insert и update и так далее. Но суть от этого не меняется. Именованый запрос.

То есть запросы к VIEW будут (значительно) медленнее, чем запросы к обычной таблице?

А сделать в порядке эксперимента простой VIEW из пары-тройки таблиц и посмотреть план выполнения простого select-а никак?

То есть запросы к VIEW будут (значительно) медленнее

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

ну только не в постгрессе. И материализованных view нету (хотя можно изобразить что-то такое на триггерах)

А сделать в порядке эксперимента простой VIEW из пары-тройки таблиц и посмотреть план выполнения простого select-а никак?

Как угодно, но это чисто академический интерес.

На LOR есть специалисты по всему, и нельзя отрицать, что среди посетителей есть клёвые DBA, которые легко прояснят этот момент.

на триггерах

Разве триггеры — это хорошо?

Являются ли представления медленнее, чем обычные таблицы? Хранятся ли они на диске или дёргаются каждый раз при запросе

В оракле бывают обычные view и материализованные. Обычные работают так: когда приходит запрос к view'шке, он объединяется с запросом, который создал view и далее строится обычный план выполнения запроса (с оптимизациями в том числе). Материализованные VIEW - это типа таблиц, в которые эти данные селектятся и сохраняются на диск (соответственно материализованные view нужно обновлять).

В Postres, view не бывает материализованным (http://www.postgresql.org/docs/current/static/sql-createview.html), но, наверняка это можно устроить другими способами. Кроме того, во view (Postgres) нельзя писать, только читать. Как строится план выполнения select, обращенного к view в Postgres, я не нашел.

Обычные работают так: когда приходит запрос к view'шке, он объединяется с запросом, который создал view и далее строится обычный план выполнения запроса (с оптимизациями в том числе).

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

а что есть выбор ?

а то - 100500-звенка!

а что есть выбор ?

Не знаю. Посмотрел ссылку вот такую http://tech.jonathangardner.net/wiki/PostgreSQL/Materialized_Views и немного ужаснулся. ☺

во view (Postgres) нельзя писать, только читать

можно, нужно лишь создать правила соответствующие на INSERT и UPDATE