Представлення (`VIEW`) в PostgreSQL

Іноді SQL-запити стають занадто великими, складними і повторюваними. Наприклад, ти будуєш звіт по студентам з їх середніми оцінками і кількістю курсів — і пишеш один і той самий підзапит у п’яти місцях. Щоб не копіпастити одне й те саме знову і знову, юзай представлення — або VIEW.

VIEW — це як “збережений запит”, якому можна дати ім’я і звертатись до нього як до таблиці. Він не зберігає дані, а лише структуру запиту.

Це особливо зручно, коли ти хочеш:

• спростити читабельність SQL-коду;
• перевикористати складну вибірку;
• сховати технічні деталі від юзерів;
• розмежувати рівні доступу (показувати тільки потрібні дані).

Як працює VIEW?

Створити представлення — це створити псевдотаблицю на основі SELECT-запиту. Наприклад:

CREATE VIEW student_avg_grades AS
SELECT 
    s.student_id,
    s.name,
    AVG(g.grade) AS avg_grade
FROM 
    students s
JOIN 
    grades g ON s.student_id = g.student_id
GROUP BY 
    s.student_id, s.name;

Тепер можна звертатись до student_avg_grades як до звичайної таблиці:

SELECT * FROM student_avg_grades WHERE avg_grade > 4.5;

Приклад з універу

Ти часто аналізуєш студентів, їх курси і оцінки. Уяви, що треба побудувати зведений звіт по кожному студенту:

• ім’я,
• кількість записів на курси,
• середня оцінка.

Якщо спробувати зробити це одним махом — вийде довгий і незручний для читання SQL. Значно зручніше розбити задачу: спочатку створимо два представлення (VIEW), а потім їх об’єднаємо.

Таблиця students

Таблиця enrollments

1. Представлення: кількість курсів

Це представлення рахує, скільки курсів у кожного студента:

CREATE VIEW student_course_count AS
SELECT 
    student_id,
    COUNT(*) AS course_count
FROM 
    enrollments
GROUP BY student_id;

Результат:

2. Представлення: середня оцінка А це — середня оцінка студента (якщо немає оцінки — NULL, і вона не впливає):

CREATE VIEW student_avg_grade AS
SELECT
student_id,
AVG(grade) AS avg_grade
FROM
enrollments
WHERE grade IS NOT NULL
GROUP BY student_id;

3. Використання цих VIEW

SELECT
    s.name,
    c.course_count,
    a.avg_grade
FROM 
    students s
LEFT JOIN student_course_count c ON s.student_id = c.student_id
LEFT JOIN student_avg_grade a ON s.student_id = a.student_id;

Тепер у тебе чистий і зрозумілий запит. А головне — його легко підтримувати.

Оновлюваність VIEW

Представлення зазвичай не містять даних — це просто "обгортка" над запитом. Але можна юзати їх навіть для оновлення даних, якщо VIEW задовольняє кільком умовам (наприклад, без JOIN, GROUP BY, агрегатів і підзапитів).

Приклад оновлюваного представлення:

CREATE VIEW active_students AS
SELECT * FROM students WHERE active = true;

Тепер можна виконувати:

UPDATE active_students SET name = 'Іван Петро' WHERE student_id = 2;

Але якщо VIEW складний (наприклад, містить JOIN або GROUP BY), він стає тільки для читання. Для оновлень можна юзати INSTEAD OF тригери, але це вже просунутий рівень.

Як видалити або змінити VIEW

Видалення:

DROP VIEW student_avg_grade;

Оновлення:

CREATE OR REPLACE VIEW student_avg_grade AS
SELECT student_id, ROUND(AVG(grade), 2) AS avg_grade
FROM grades
GROUP BY student_id;

Приклади: коли VIEW особливо корисний

1. Побудова звітів

Один VIEW — одна логіка. Ти можеш налаштувати report_enrollments_by_month, report_payments_by_year і т.д.

2. Розмежування доступу

Створи VIEW, який показує тільки обмежені дані (наприклад, без персональних даних) і дай доступ тільки до нього.

3. Перевикористання

Замість того щоб копіпастити підзапит — дай йому ім’я у вигляді VIEW.

Поради

• Давайте зрозумілі імена: view_avg_scores_by_group, active_users_view — так легше читати.
• Не робіть ланцюжки VIEW в VIEW в VIEW — це ускладнює розуміння і дебаг.
• Слідкуйте за продуктивністю: PostgreSQL буде перераховувати VIEW при кожному запиті, якщо це не MATERIALIZED VIEW.

VIEW — один з найпростіших і найзручніших інструментів у PostgreSQL. Вони не вимагають нових знань, тільки переосмислення: «А може, зберегти цей запит і юзати як таблицю?» Якщо твій запит стає громіздким — майже напевно він заслуговує стати VIEW.