Представления в PostgreSQL: короткое руководство

Что получится и что понадобится

За 10–15 минут вы создадите представление в PostgreSQL, проверите его обычным запросом и обновите определение без удаления объекта. Примеры подходят для PostgreSQL 16; базовый синтаксис представлений давно стабилен, но особенности прав и оптимизации сверяйте с документацией вашей версии.

До начала подготовьте доступ к базе и таблицу, из которой можно читать данные. В примерах используется таблица orders с полями id, customer_id, status, total и created_at. Если у вас другая схема, замените имена таблицы и столбцов на свои. Запросы можно выполнять в psql или в SQL-редакторе вашей среды.

Создайте представление

Обычное представление — сохранённый запрос с именем. Оно не копирует строки в отдельное хранилище: при обращении к нему PostgreSQL выполняет связанный запрос, используя актуальные данные базовых таблиц.

1. Выберите стабильные имена и состав данных. Пусть представление отдаёт только оплаченные заказы, которые нужны отчёту. Не включайте все столбцы автоматически: если схема таблицы изменится, явный список полей проще проверять. Проверка: вы можете объяснить, кто и для какой задачи будет читать каждое поле.
2. Создайте представление. Выполните запрос ниже. Проверка: сервер ответит сообщением о создании представления без ошибки.

CREATE VIEW paid_orders AS
SELECT id, customer_id, total, created_at
FROM orders
WHERE status = 'paid';

1. Прочитайте результат. Представление используют в запросе почти как таблицу. Проверка: запрос возвращает строки, соответствующие условию по статусу.

SELECT id, customer_id, total, created_at
FROM paid_orders
ORDER BY created_at DESC
LIMIT 20;

Это именно обычное представление: оно хранит определение запроса, а не готовый набор результатов. Поэтому свежие изменения в orders видны при следующем обращении, если запрос к представлению их выбирает.

Поменяйте определение и проверьте результат

Когда отчёту понадобится ещё одно поле, не обязательно удалять представление и создавать заново. Для существующего объекта используйте CREATE OR REPLACE VIEW. Список выходных столбцов должен сохранить прежние имена, порядок и типы; новые столбцы можно добавлять в конец. Если нужно переименовать или изменить существующий столбец, безопаснее спланировать миграцию зависимых запросов и объектов, а не рассчитывать, что замена примет любое изменение.

CREATE OR REPLACE VIEW paid_orders AS
SELECT id, customer_id, total, created_at, status
FROM orders
WHERE status = 'paid';

После выполнения проверьте не только отсутствие ошибки, но и фактическую форму результата: например, запросите несколько строк и посмотрите названия и типы столбцов. Если другие представления или приложения зависят от исходной формы, добавление столбца тоже стоит проверить в тестовой среде.

Проверка через SQL полезна, но не заменяет проверку плана и времени выполнения. Представление само по себе не гарантирует ускорение: планировщик обычно включает его запрос в общий запрос и оптимизирует результат вместе с ним. При тяжёлом фильтре или соединении измеряйте запрос с реальными параметрами и объёмом данных.

Когда представление удобно

• Повторяющаяся выборка. Один и тот же фильтр или соединение нужен нескольким отчётам. Представление задаёт общую точку обращения, а не копию запроса в каждом месте.
• Упрощённый интерфейс к схеме. Потребителю можно показать выбранные столбцы и скрыть детали базовых таблиц. Это помогает отделить отчёт от части изменений внутри схемы, но не отменяет проверку совместимости при изменении интерфейса.
• Разделение обязанностей. Разработчик может менять внутренние запросы, сохраняя контракт представления для потребителя, если сохраняет его столбцы и смысл.

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

Сноска. План запроса — описание того, как PostgreSQL собирается получить результат: например, каким способом прочитать таблицу и соединить её с другой. Чтобы увидеть план и фактическое время выполнения, используют EXPLAIN и EXPLAIN ANALYZE; последний действительно выполняет запрос.

Права и изменяемость: проверьте до передачи приложения

Представление может дать пользователю доступ к ограниченному набору столбцов, но это не универсальная замена настройке безопасности. Проверьте, кому выдали права на базовые таблицы и само представление, и какой режим проверки прав нужен. В PostgreSQL 15 и новее у представлений есть параметр security_invoker: он меняет то, чьи права применяются при обращении. Не включайте его или не полагайтесь на права владельца без понимания последствий для вашей схемы. Сверяйте точное поведение с документацией версии сервера.

Не всякое представление можно изменить через INSERT, UPDATE или DELETE. Простое представление над одной таблицей часто допускает такие операции, если запрос удовлетворяет ограничениям PostgreSQL. Агрегаты, группировки, объединения и некоторые другие конструкции делают изменение неоднозначным: серверу может быть неясно, какую именно строку исходной таблицы менять. Для такого случая существуют правила и триггеры на представления, но их не стоит добавлять без отдельной проверки поведения.

Если не получилось

• relation "orders" does not exist. PostgreSQL не нашёл таблицу с таким именем в текущей схеме и поисковом пути. Проверьте схему, регистр имени и доступность таблицы; при необходимости укажите схему явно, например public.orders.
• column "status" does not exist. В таблице нет столбца с таким именем или он создан с нестандартным регистром в кавычках. Сверьте фактическую схему и исправьте запрос.
• permission denied for table orders. У текущей роли нет нужного доступа к базовой таблице. Проверьте права и настройки безопасности представления вместе с администратором базы, не выдавая приложению лишние привилегии.
• Представление создано, но запрос медленный. Это не означает, что оно хранит или кеширует результат. Сравните план исходного запроса и запроса через представление на тех же данных; проверьте фильтры, соединения и индексы базовых таблиц.

Обычное или материализованное

Если повторный расчёт дорогой и допустимо, что результат некоторое время будет устаревшим, рассмотрите материализованное представление. В отличие от обычного, оно сохраняет результат запроса; после изменений исходных данных результат нужно обновлять командой REFRESH MATERIALIZED VIEW. Это обмен времени чтения на место хранения и работу по обновлению, а не бесплатное ускорение.

Что делать дальше

Сначала создайте обычное представление в тестовой схеме и проверьте его вместе с приложением, которое будет его читать. Затем измерьте запрос через EXPLAIN ANALYZE на данных, близких к рабочим, и проверьте права отдельной роли приложения. Если узкое место — повторный расчёт, сравните его стоимость с обновлением материализованного представления и заранее решите, насколько свежими должны быть данные.