LINUX.ORG.RU

Индексы

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

power ()
Ответ на: комментарий от baverman

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

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

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

eveel ★★ ()
Ответ на: комментарий от eveel

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

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

baverman ★★★ ()
Ответ на: комментарий от eveel

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

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

no-dashi ★★★★★ ()
Ответ на: комментарий от no-dashi

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

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

eveel ★★ ()
Ответ на: комментарий от baverman

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

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

no-dashi ★★★★★ ()
Ответ на: комментарий от eveel

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

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

Absurd ★★★ ()
Ответ на: комментарий от eveel

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

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

no-dashi ★★★★★ ()
Ответ на: комментарий от baverman

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

maxcom ★★★★★ ()
Ответ на: комментарий от Absurd

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

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

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

eveel ★★ ()
Ответ на: комментарий от eveel

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

maxcom ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

unC0Rr ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.