Уроки модуля (4/4)
Представления и абстракция данных
На протяжении наших уроков вы заметили, что запросы (особенно сложные JOIN или агрегаты типа GROUP BY) начинают становиться длинными и полными правил и вычислений.
Что, если бы существовал способ мысленно сохранить завершенный запрос и скрыть его от просмотра, притворяясь с этого момента, что это, по сути, обычная «таблица» БД?
Добро пожаловать в мир просмотров.
СОЗДАТЬ ПРОСМОТР
Представление, по сути, представляет собой постоянный именованный SQL-запрос, но он ведет себя так же, как «виртуальная» таблица!
CREATE VIEW user_spending AS
SELECT
c.id,
c.first_name,
SUM(o.amount) as total_spent
FROM customers c
JOIN orders o ON c.id = o.customer_id
GROUP BY c.id;Сделанный! Теперь вместо того, чтобы постоянно переделывать JOIN и GROUP BY, вам просто нужно написать совершенно нормальные запросы:
SELECT * FROM user_spending WHERE total_spent > 100;
-- Postgres dietro le quinte richiamerà automaticamente la grande formula.Просмотры и «данные в реальном времени»
Очень распространенный миф заключается в том, что Views берет данные, вычисляет суммы, такие как цены или рейтинги, и создает какой-то печальный постоянный снимок, например фотографию. Неправильно (почти всегда)! По умолчанию представления виртуальные: каждый раз, когда вы помещаете имя представления в свой SELECT, Postgres незаметно объединяет ваш запрос, выполняя вычисления в реальном времени на основе состояния БД в эту точную миллисекунду. Таким образом, вы никогда не будете читать устаревшие данные.
Для чего они нужны?
- Простота: представления защищают внешние приложения от изменений. Если команда внешнего интерфейса знает, что ей нужно считывать данные из представления
top_selling, им не придется беспокоиться, если завтра мы изменим базу данных, добавив три промежуточных отношения, чтобы выявить лидеров продаж! - Безопасность и сегрегация: в огромных БД представление может предварительно выбирать и скрывать часть пользовательских данных от внешних разработчиков, предоставляя им доступ (например) только к подпредставлению аналитики, очищенному от реальных имен.
Удаление представления
Как и в случае с таблицами, когда они больше не нужны, вы можете использовать команду DROP:
DROP VIEW user_spending;Попробуйте это
Создайте представление (VIEW) под названием «high_value_products». Он должен вести себя как контейнер, который выбирает все три основных поля («id», «имя», «цена») из таблицы «продукты», НО только и всегда для тех продуктов, «цена» которых превышает 50,00.
Показать подсказку
Напишите CREATE VIEW имя_представления AS SELECT... FROM... WHERE...
Решение доступно после 3 попыток
Вызов представления
Поскольку каждое упражнение на платформе выполняется в изолированной (и чистой) среде, предыдущее представление на этом этапе больше не существует. Воссоздайте представление «high_value_products» (все еще с продуктами с ценой > 50), а затем в следующей строке запустите ВЫБОР всего его содержимого, упорядоченного по убыванию цены (DESC), чтобы убедиться, что оно работает.
Показать подсказку
Не забывайте ; между операторами SQL (поместите его в конце первой строки)! Это позволяет Postgres последовательно выполнять две задачи.
Решение доступно после 3 попыток