diff --git a/dmedvedev/views.sql b/dmedvedev/views.sql
new file mode 100644
index 0000000..cc41536
--- /dev/null
+++ b/dmedvedev/views.sql
@@ -0,0 +1,78 @@
+--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
+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 для отчётов (какие ошибки могут появиться в анализе)?
+Слишком редкое обновление грозит тем, что не будут учтены свежие данные, соответственно выборка может быть неактуальной.
+
+Почему нельзя обновлять витрины «каждую секунду», даже если хочется всегда свежие данные?
+Потому что это дополнительная нагрузка на систему, на базу данных.
+*/
\ No newline at end of file