Перейти к основному содержимому
Модуль 9 · Урок 4 из 436/57 в курсе~12 min
Уроки модуля (4/4)

Представления и абстракция данных

На протяжении наших уроков вы заметили, что запросы (особенно сложные JOIN или агрегаты типа GROUP BY) начинают становиться длинными и полными правил и вычислений.

Что, если бы существовал способ мысленно сохранить завершенный запрос и скрыть его от просмотра, притворяясь с этого момента, что это, по сути, обычная «таблица» БД?

Добро пожаловать в мир просмотров.

СОЗДАТЬ ПРОСМОТР

Представление, по сути, представляет собой постоянный именованный SQL-запрос, но он ведет себя так же, как «виртуальная» таблица!

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, вам просто нужно написать совершенно нормальные запросы:

SQL
SELECT * FROM user_spending WHERE total_spent > 100;
-- Postgres dietro le quinte richiamerà automaticamente la grande formula.

Просмотры и «данные в реальном времени»

Очень распространенный миф заключается в том, что Views берет данные, вычисляет суммы, такие как цены или рейтинги, и создает какой-то печальный постоянный снимок, например фотографию. Неправильно (почти всегда)! По умолчанию представления виртуальные: каждый раз, когда вы помещаете имя представления в свой SELECT, Postgres незаметно объединяет ваш запрос, выполняя вычисления в реальном времени на основе состояния БД в эту точную миллисекунду. Таким образом, вы никогда не будете читать устаревшие данные.

Для чего они нужны?

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

Удаление представления

Как и в случае с таблицами, когда они больше не нужны, вы можете использовать команду DROP:

SQL
DROP VIEW user_spending;

Попробуйте это

Упражнение#sql.m9.l4.e1
Попыток: 0Загрузка…

Создайте представление (VIEW) под названием «high_value_products». Он должен вести себя как контейнер, который выбирает все три основных поля («id», «имя», «цена») из таблицы «продукты», НО только и всегда для тех продуктов, «цена» которых превышает 50,00.

Загрузка редактора…
Показать подсказку

Напишите CREATE VIEW имя_представления AS SELECT... FROM... WHERE...

Решение доступно после 3 попыток

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

Упражнение#sql.m9.l4.e2
Попыток: 0Загрузка…

Поскольку каждое упражнение на платформе выполняется в изолированной (и чистой) среде, предыдущее представление на этом этапе больше не существует. Воссоздайте представление «high_value_products» (все еще с продуктами с ценой > 50), а затем в следующей строке запустите ВЫБОР всего его содержимого, упорядоченного по убыванию цены (DESC), чтобы убедиться, что оно работает.

Загрузка редактора…
Показать подсказку

Не забывайте ; между операторами SQL (поместите его в конце первой строки)! Это позволяет Postgres последовательно выполнять две задачи.

Решение доступно после 3 попыток