Создание представлений: CREATE VIEW — сохранённый запрос как виртуальная таблица

Что такое представление в SQL? 🧐

Представление (VIEW) — это виртуальная таблица, которая не хранит данные физически, а представляет результат SQL-запроса. Это как сохранить часто используемый запрос под именем и обращаться к нему, как к обычной таблице!

Почему это круто?
✔ Упрощает сложные запросы
✔ Обеспечивает безопасность данных (скрывает ненужные столбцы)
✔ Упрощает работу с часто используемыми выборками
✔ Экономит время на повторном написании запросов

Как создать представление? 🏗️

Базовый синтаксис прост, как пирог:

CREATE VIEW view_name AS
SELECT column1, column2, ...
FROM table_name
WHERE condition;

🔥 Живой пример: создадим представление для активных пользователей из Москвы

CREATE VIEW active_moscow_users AS
SELECT user_id, name, email, registration_date
FROM users
WHERE city = 'Москва' 
  AND is_active = TRUE;

Теперь можно запрашивать данные как из обычной таблицы:

SELECT * FROM active_moscow_users 
WHERE registration_date > '2023-01-01';

Обновляемые представления 🔄

Некоторые представления можно не только читать, но и изменять! Условия для обновляемого представления:

Должно содержать только одну таблицу в FROM
Не должно иметь DISTINCT, GROUP BY, агрегатных функций
Должно включать все NOT NULL столбцы базовой таблицы

Пример:

CREATE VIEW editable_products AS
SELECT product_id, name, price, category
FROM products
WHERE is_available = TRUE;

Теперь можно делать:

UPDATE editable_products 
SET price = price * 1.1 
WHERE category = 'Electronics';

Материализованные представления 💾

В некоторых СУБД (PostgreSQL, Oracle) есть особый тип — материализованные представления, которые хранят данные физически и могут обновляться по расписанию.

Пример для PostgreSQL:

CREATE MATERIALIZED VIEW expensive_products AS
SELECT * FROM products
WHERE price > 1000
WITH DATA;

-- Обновляем данные вручную
REFRESH MATERIALIZED VIEW expensive_products;

Вложенные представления 🎭

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

CREATE VIEW premium_users_stats AS
SELECT 
    u.user_id,
    u.name,
    COUNT(o.order_id) as total_orders,
    SUM(o.amount) as total_spent
FROM active_moscow_users u  -- наше первое представление!
JOIN orders o ON u.user_id = o.user_id
GROUP BY u.user_id, u.name
HAVING SUM(o.amount) > 10000;

Когда использовать представления? 🤔

✅ Часто повторяющиеся сложные запросы
✅ Необходимость ограничить доступ к данным
✅ Сложные бизнес-правила, скрытые от конечного пользователя
✅ Агрегация данных для отчетности

Ограничения представлений ⚠️

Производительность: сложные представления могут работать медленнее
Некоторые представления нельзя обновлять
Зависимости: изменение структуры таблиц может сломать представления

Практический пример из жизни 🏦

Создадим аналитическую панель для интернет-магазина:

-- Представление для клиентов VIP-уровня
CREATE VIEW vip_customers AS
SELECT 
    c.customer_id,
    c.name,
    c.email,
    SUM(o.total_amount) as lifetime_value,
    COUNT(o.order_id) as total_orders
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name, c.email
HAVING SUM(o.total_amount) > 50000;

-- Представление для ежемесячных продаж
CREATE VIEW monthly_sales AS
SELECT 
    DATE_TRUNC('month', order_date) as month,
    product_category,
    SUM(quantity) as total_quantity,
    SUM(total_amount) as revenue
FROM orders
GROUP BY DATE_TRUNC('month', order_date), product_category;

Теперь аналитики могут работать с этими данными, не зная сложностей исходной структуры БД!

Продвинутый лайфхак 🔥

Используйте WITH CHECK OPTION для представлений, которые изменяют данные. Это гарантирует, что измененные или добавленные строки будут видны через представление:

CREATE VIEW recent_orders AS
SELECT * FROM orders
WHERE order_date > CURRENT_DATE - INTERVAL '30 days'
WITH CHECK OPTION;

Теперь при попытке изменить дату заказа на более старую через это представление система выдаст ошибку!

Лучшие практики работы с представлениями 🏆

Давайте осмысленные имена (sales_report_2023, а не view1)
Документируйте представления комментариями
Избегайте излишней вложенности (не более 2-3 уровней)
Тестируйте производительность сложных представлений