Dmitry Medvedev
79 lines
4.7 KiB
SQL
79 lines
4.7 KiB
SQL
--task 1
|
|
--Задание 1. Витрина выручки по категориям
|
|
CREATE MATERIALIZED VIEW mv_category_revenue AS
|
|
SELECT
|
|
p.category,
|
|
SUM(oi.quantity * oi.price_at_purchase) AS total_revenue
|
|
FROM products p
|
|
JOIN order_items oi
|
|
ON oi.product_id = p.id
|
|
JOIN orders o
|
|
ON o.id = oi.order_id
|
|
WHERE o.status = 'paid'
|
|
GROUP BY p.category
|
|
ORDER BY total_revenue DESC;
|
|
/*Чем удобно иметь готовую витрину по категориям, вместо того чтобы каждый раз писать JOIN по трём таблицам?
|
|
Тем что не нужно постоянно писать запросы, которые используешь часто, достаточно один раз написать верный view и не париться, больше останется времени на остальную работу.
|
|
*/
|
|
|
|
--task 2
|
|
--Задание 2. Витрина активности пользователей
|
|
CREATE MATERIALIZED VIEW mv_user_activity AS
|
|
SELECT
|
|
o.user_id AS user_id,
|
|
u.name AS user_name,
|
|
COUNT(*) AS orders_count
|
|
FROM users u
|
|
JOIN orders o
|
|
ON o.user_id = u.id
|
|
WHERE o.status = 'paid'
|
|
GROUP BY o.user_id, u.name
|
|
ORDER BY orders_count DESC;
|
|
|
|
/*Как по такой витрине найти «самых лояльных» клиентов?
|
|
Выбрать тех у кого оплаченных заказов наибольшее количество
|
|
|
|
Что будет, если считать активность не по всем заказам, а только за последние 30 дней — как изменится смысл витрины?
|
|
В таком случае мы будем видеть самых горячих клиентов, возможно, готовых совершить следующий заказ, но с другой стороны здесь можно и ошибаться.
|
|
*/
|
|
|
|
--task 3
|
|
--Задание 3. Витрина выручки по дням
|
|
CREATE MATERIALIZED VIEW mv_daily_revenue AS
|
|
SELECT
|
|
order_date::date AS sales_date,
|
|
SUM(quantity * price_at_purchase) AS daily_revenue
|
|
FROM orders o
|
|
JOIN order_items oi
|
|
ON o.id = oi.order_id
|
|
WHERE o.status = 'paid'
|
|
GROUP BY o.order_date::date
|
|
ORDER BY sales_date;
|
|
|
|
/*
|
|
Как по такой витрине заметить «просадки» и «пики» продаж?
|
|
видно будет в какой день какая выручка.
|
|
|
|
Что быстрее: считать выручку «на лету» из сырых таблиц или читать из mv_daily_revenue? Почему?
|
|
конечно же из mv_daily_revenue, потому что это таблица , которая уже создана, это быстрее, но минус в том, что она не обновляется, пока не сделаешь refresh самостоятельно.
|
|
*/
|
|
|
|
--task 4
|
|
--Задание 4. Обновление витрин
|
|
|
|
REFRESH MATERIALIZED VIEW mv_category_revenue;
|
|
|
|
/*Для интернет‑магазина с несколькими заказами в день я бы внедрил автоматическое обновление как можно чаще,
|
|
например, ежечасно, возможно получится обнаружить какие-то определенные паттерны у пользователей, чтобы
|
|
попробовать увеличить количество заказов будущем.
|
|
|
|
А для крупного магазина с тысячами заказов в час нужно внедрять систему с редкими обновлениями.
|
|
Во-первых частые обновления не смогут принести какую-то полезную информацию, а во-вторых это большая нагрузка на систему.
|
|
Для такого бизнеса важно сводить кассу к концу дня. И в конце, например, месяца формировать отчеты, когда и что больше всего покупалось.
|
|
|
|
Чем грозит слишком редкий REFRESH для отчётов (какие ошибки могут появиться в анализе)?
|
|
Слишком редкое обновление грозит тем, что не будут учтены свежие данные, соответственно выборка может быть неактуальной.
|
|
|
|
Почему нельзя обновлять витрины «каждую секунду», даже если хочется всегда свежие данные?
|
|
Потому что это дополнительная нагрузка на систему, на базу данных.
|
|
*/ |