Руководство по созданию эффективных запросов

Листинг 7.11 

Создаем материализованное представление из подзапроса
CREATE MATERIALIZED VIEW passenger_passport AS
SELECT cf.passenger_id,
coalesce(max(CASE WHEN custom_field_name = 'passport_num'
THEN custom_field_value ELSE NULL
END),'') AS passport_num,
coalesce(max(CASE WHEN custom_field_name = 'passport_exp_date'
THEN custom_field_value ELSE NULL
END),'') AS passport_exp_date,
coalesce(max(CASE WHEN custom_field_name = 'passport_country'
THEN custom_field_value ELSE NULL
END),'') AS passport_country
FROM custom_field cf
GROUP BY 1
Кажется, что это материализованное представление будет очень полезно. 
Во-первых, уже было показано, что для выполнения такого запроса требуется 
много времени, поэтому можно сэкономить за счет предварительного рас-

---

150

Длинные запросы: дополнительные приемы
чета результатов. Во-вторых, паспортные данные не меняются (эта информа-
ция связана с бронированием, и одному и тому же человеку будет назначать-
ся иной идентификатор 
passenger_id
при другом бронировании). Этот запрос 
был бы отличным кандидатом на роль материализованного представления, 
если бы не несколько потенциальных проблем.
Во-первых, пассажиры не обязаны указывать свои паспортные данные при 
бронировании. Хотя после ввода информация уже не меняется, но паспорт-
ные данные могут быть введены в любой момент до закрытия выхода на 
посадку. Следовательно, это материализованное представление необходимо 
постоянно обновлять, и каждое обновление занимает около 10 минут.
Во-вторых, это материализованное представление будет расти. В отличие 
от предыдущего примера, в котором ежедневное обновление охватывает 
данные исключительно за предыдущий день, количество паспортных дан-
ных будет увеличиваться, и обновление материализованного представления 
будет занимать все больше и больше времени.
Такие ситуации часто упускаются из виду на ранней стадии проекта, когда 
во всех таблицах мало данных и материализованные представления обновля-
ются быстро. Поскольку PostgreSQL не допускает инкрементное обновление 
материализованных представлений, возможным решением будет создание 
другой таблицы с той же структурой, что и материализованное представле-
ние из лис тинга 7.11, и периодическое обновление строк, когда появляются 
новые паспортные данные.
Однако, если будет принято такое решение, не понятно, зачем вообще 
нужна таблица 
custom_field
, если данные необходимы в формате, заданном 
материализованным представлением 
passenger_passport
. Это будет темой 
следующей главы, в которой обсуждается влияние проектирования схемы 
данных на производительность.