--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 для отчётов (какие ошибки могут появиться в анализе)? Слишком редкое обновление грозит тем, что не будут учтены свежие данные, соответственно выборка может быть неактуальной. Почему нельзя обновлять витрины «каждую секунду», даже если хочется всегда свежие данные? Потому что это дополнительная нагрузка на систему, на базу данных. */