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

За 15–20 минут вы создадите в PostgreSQL 16 представление, которое объединяет товары с заказами, и проверите его запросом. Представление хранит текст запроса, а не отдельную копию строк: это удобно для повторяющихся выборок, но не ускоряет их автоматически.

Что понадобится

Нужна тестовая база PostgreSQL 16 и учётная запись с правом создавать таблицы и представления в выбранной схеме. Подключиться можно через psql, pgAdmin или другой SQL-клиент. Примеры ниже выполняйте по порядку в одной базе; они создают схему demo_views, таблицы и тестовые данные.

Представление (view)¹ — именованный запрос, к которому можно обращаться почти как к таблице. Обычное представление само по себе не хранит результат запроса.

Создаём представление по шагам

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

   CREATE SCHEMA demo_views;

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

2. Создайте таблицы и добавьте данные. В примере у товара есть название и цена, а у заказа — ссылка на товар, количество и статус.

   CREATE TABLE demo_views.products (
       product_id integer PRIMARY KEY,
       name text NOT NULL,
       price numeric(10, 2) NOT NULL
   );
   
   CREATE TABLE demo_views.orders (
       order_id integer PRIMARY KEY,
       product_id integer NOT NULL REFERENCES demo_views.products(product_id),
       quantity integer NOT NULL,
       status text NOT NULL
   );
   
   INSERT INTO demo_views.products (product_id, name, price) VALUES
       (1, 'Клавиатура', 4500.00),
       (2, 'Мышь', 1800.00);
   
   INSERT INTO demo_views.orders (order_id, product_id, quantity, status) VALUES
       (101, 1, 2, 'paid'),
       (102, 2, 1, 'new');

   Проверка: выполните SELECT * FROM demo_views.orders; — должны вернуться две строки. Если таблицы уже есть, не запускайте этот шаг повторно без очистки тестовых объектов.

3. Опишите представление. Оно покажет только оплаченные заказы и рассчитает сумму строки. Явные имена столбцов упрощают дальнейшие запросы.

   CREATE VIEW demo_views.paid_order_lines AS
   SELECT
       o.order_id,
       p.name AS product_name,
       o.quantity,
       p.price,
       o.quantity * p.price AS line_total
   FROM demo_views.orders AS o
   JOIN demo_views.products AS p
       ON p.product_id = o.product_id
   WHERE o.status = 'paid';

   Проверка: PostgreSQL должен сообщить, что представление создано. Если получите ошибку о существующем объекте, проверьте его через \dv demo_views.* в psql либо список объектов схемы в вашем SQL-клиенте.

4. Прочитайте данные через представление. Вызов выглядит как обычная выборка из таблицы:

   SELECT order_id, product_name, quantity, line_total
   FROM demo_views.paid_order_lines
   ORDER BY order_id;

   Проверка: вернётся одна строка с заказом 101 и суммой 9000.00. Заказ со статусом new не попадёт в результат.

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

   UPDATE demo_views.orders
   SET status = 'paid'
   WHERE order_id = 102;
   
   SELECT order_id, product_name, quantity, line_total
   FROM demo_views.paid_order_lines
   ORDER BY order_id;

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

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

Представление помогает дать одинаковое имя часто используемому соединению таблиц и расчёту. Вместо копирования длинного запроса в отчёт, админку и внутренний инструмент каждый клиент может читать demo_views.paid_order_lines. Если схема исходных таблиц меняется, представление также может служить стабильным слоем между ней и потребителями — но только если его контракт поддерживают и проверяют.

Представление упрощает повторное использование запроса, а не стоимость его выполнения: если внутри тяжёлое соединение, оно останется тяжёлым.

Обычное представление не является кэшем. Для хранения результата используют материализованное представление, которое нужно обновлять отдельно; это другой механизм и отдельное решение о свежести данных. Не заменяйте одно другим только ради похожего синтаксиса.

Что может пойти не так

• Представление создано, но запрос медленный. Оно не гарантирует ускорения. Посмотрите план выполнения исходного запроса с EXPLAIN, проверьте соединения и индексы на исходных таблицах.

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

• Запрос неожиданно возвращает пустой результат. Сверьте условие WHERE и реальные значения статуса. В примере фильтр требует точного совпадения со строкой paid.

• После изменения структуры таблицы запрос перестал работать. Проверьте определение представления и зависимые объекты. Изменения схемы нужно планировать вместе с запросами, которые на неё опираются.

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

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

¹ Термин «представление» в PostgreSQL соответствует SQL-объекту view; материализованное представление (materialized view) сохраняет результат запроса на диске и не обновляется автоматически при каждом чтении.