В чем практическая разница применения отдельной таблицы или MATERIALIZED VIEW
Дана достаточно раскидистая структура данных большого объема. Логика моей программы требует работы с определенной выборкой из этих таблиц. Выборка происходит достаточно долгое время и, чтобы ускорить процесс, я решил, что нужна временная таблица, в которую я один раз сделаю выборку и затем буду общаться только с этой временной таблицей, периодически ее обновляя. Но, почитав документацию к PostgreSQL, я нашел такой инструмент как MATERIALIZED VIEW, который, судя по тому, что я понял как раз подходит для моих целей.
Вопрос
В чем практическая разница (по вашему опыту и знаниям) в применении отдельной временной таблицы против применения MATERIALIZED VIEW. Документацию я читал, та разница, которая описана в первом же абзаце мне понятна. Меня интересуют другие моменты, например, что будет быстрее работать или что практически удобнее.
Ответы (1 шт):
Насколько я понимаю, тут разница именно в том, устраивает вас слегка устаревший кэш ваших данных или нет. И каков вообще ваш процесс использования этих данных.
- Если вы делаете какой-то отчёт или группу отчётов и для вас не критично подождать пока сформируется временная таблица, а потом вы сгенерируете из неё некие отчёты и удалите эту временную таблицу - ну, ок, временная таблица для вас самое то.
- Если же вам нужно периодически получать какие-то отчёты по данным, при этом вы не хотите долго ждать, пока данные обновляются, а получить отчёты как можно быстрее, пусть данные при этом будут не самые свежие - вот тут materialized view по идее самое то. Это как бы кэш ваших данных, обновляемый "по запросу".
Конечно, такой устаревающий кэш можно сделать и в таблице БД, казалось бы какая разница тогда? Но разница всё же есть. Временные таблицы на то и временные, что они не должны долго жить. Если вы хотите пользоваться таблицей всё время, то это уже постоянная таблица.
Ок, вы можете сделать постоянную таблицу и обновлять её через какую-то процедуру. Чем это плохо? На мой взгляд это плохо тем, что у вас два разных объекта в БД и вы должны знать, какая между ними связь. Отдельно таблица и отдельно процедура, которая обновляет эту таблицу. В случае же MV у вас таблица и процедура обновления - это один объект, есть чёткая инструкция, как вам обновить данные в MV, эта процедура одинаковая для любого MV, всё чётко и понятно.
Кроме того, не знаю как Postgresql, но во многих продвинутых БД есть разные стратегии обновления MV. Они могут обновляться автоматически, например, при обновлении данных в таблицах, на которых они построены. Или, если не путаю, то по времени - скажем, раз в сутки. Что в общем удобно. Не нужно настраивать ещё и запуск процедуры по времени, сразу всё зашито в MV - и данные, и процедура их обновления, и стратегия/расписание обновления. По-моему это просто удобно.