dmedvedev/agregation.sql

@@ -0,0 +1,130 @@
+--task 1
+--Задача 1. Сколько товаров в каждой категории
+SELECT p.category, COUNT (*) AS products_count
+FROM products p 
+
+GROUP BY category
+ORDER BY products_count DESC
+
+/*Что будет, если убрать ORDER BY — как изменится чтение результата для продукта/аналитика?
+Аналитик может пропустить товар с самым большим значением или с самым малым
+
+Если добавить в таблицу новый товар с категорией smartphone, как изменится строка для этой категории?
+Тогда количество увеличится на 1
+*/
+
+--таск 2
+--Задача 2. Выручка по каждому заказу
+
+SELECT order_id, SUM(quantity) AS total_quantity, SUM(quantity * price_at_purchase) AS order_revenue
+FROM order_items oi 
+
+GROUP BY order_id
+ORDER BY order_revenue DESC
+
+/*Что будет, если убрать GROUP BY и оставить SUM(quantity * price_at_purchase)?
+Будет ошибка, так как order_id нигде не задействовано
+
+Почему нельзя просто добавить в SELECT ещё одну колонку (например, product_id) без добавления её в GROUP BY или агрегат?
+Потому что при использовании агрегатных функций всегда что-то должно по чему-то группироваться, в данном случае идет группировка по order_id, если добавить что-то другое в селект, то нужно будет это тоже использовать в GROUP BY 
+*/
+
+--таск 3
+--Задача 3. Выручка по категориям товаров
+SELECT category, SUM (oi.quantity * oi.price_at_purchase) AS category_revenue
+FROM order_items oi 
+JOIN products p ON oi.product_id = p.id
+GROUP BY p.category 
+ORDER BY category_revenue DESC
+
+/*Почему группировка идёт по p.category, а не по p.id?
+Задача была группировать по категориям, поэтому так. Если бы задача была группировать по айдишникам продуктов, то да, делали бы так.
+
+Если добавить в SELECT ещё p.name, что произойдёт с результатом и почему?
+Выдаст ошибку, потому что p.name дальше не используется ни в агрегате ни в группировке.
+*/
+
+--таск 4
+--Задача 4. Только оплаченные заказы и их выручка
+SELECT COUNT(order_id), SUM (oi.quantity * oi.price_at_purchase) AS order_revenue
+FROM order_items oi 
+JOIN orders o ON oi.order_id = o.id
+WHERE status = 'paid'
+ORDER BY order_revenue DESC
+
+/*
+Чем результат этой задачи будет отличаться от задачи 2 (где статус не учитывался)?
+Во-первых здесь в выдаче одна строчка, во-вторых во второй задаче суммировались все заказы, даже не оплаченные.
+
+В какой реальной ситуации ты бы смотрел только на paid заказы, а не на все?
+Когда необходимо подбить сколько именно денег пришло на счет за определенный период.
+*/
+
+--таск 5
+--Задача 5. Категории с выручкой больше 1000 (HAVING)
+SELECT category, SUM (oi.quantity * oi.price_at_purchase) AS category_revenue
+FROM order_items oi 
+JOIN products p ON oi.product_id = p.id
+GROUP BY p.category 
+ORDER BY category_revenue DESC
+
+/* Почему нельзя написать WHERE category_revenue > 1000?
+Потому что where фильтрует только строки, а не группы 
+
+Чем WHERE price > 1000 принципиально отличается от HAVING SUM(...) > 1000?
+
+Принципиально отличается тем что именно фильтруется и тем когда это делается, 
+WHERE ставится до GROUP BY, а HAVING уже после GROUP BY
+*/
+
+--таск 6
+--Задача 6. Страны с достаточным числом активных пользователей
+SELECT country, COUNT(*) AS active_users_count 
+FROM users u
+WHERE is_active IS TRUE
+GROUP BY country
+HAVING COUNT(*) >= 2
+ORDER BY active_users_count DESC
+
+/*
+Почему фильтр по активности (is_active = true) логичнее писать в WHERE, а не в HAVING?
+Потому что WHERE проверяет каждую строку, а у HAVING другая функция
+
+Что покажет запрос, если в данных пока нет ни одной страны с active_users_count >= 2?
+Запрос покажет пустую таблицу без данных
+*/
+
+--таск 7
+--Задача 7. Топ‑товары по количеству продаж
+SELECT p.name product_name, SUM(quantity) AS total_quantity_sold
+FROM order_items oi 
+JOIN products p ON oi.product_id = p.id
+GROUP BY product_name
+ORDER BY SUM(quantity) DESC
+LIMIT 3
+
+/*
+Чем рейтинг по total_quantity_sold отличается от рейтинга по выручке (SUM(quantity * price_at_purchase))?
+Тем что мы видим самые продаваемые товары, которые имеют наибольшую популярность и здесь появляются вопросы , а почему так? продаем слишком дешево или товары слишком классные?
+В любом случае для бизнеса лучше всего поднять цену на такие товары, чтобы они приносили больше прибыли. 
+
+В каких случаях бизнесу важнее смотреть на количество, а не на деньги?
+Я думаю что количество всегда важнее, а лучше и количество и выручка. Именно количество дает понимание оборачиваемости по продукту и его востребованности. 
+Бывают товары с большой стоимостью и маленьким количеством продаж относительно других, такие товары неликвидны.
+*/
+
+--таск 8
+--Задача 8. Заказы с «маленькой» выручкой
+SELECT order_id, SUM(quantity * price_at_purchase) AS order_revenue
+FROM order_items oi 
+GROUP BY order_id
+HAVING SUM(quantity * price_at_purchase) < 100
+ORDER BY SUM(quantity * price_at_purchase)
+
+/*
+Какие реальные причины могут быть у очень маленьких заказов (1–2 гипотезы)?
+Заниженная цена, неликвидность товара. 
+
+Что проще увидеть глазами: просто все заказы с суммой или именно отфильтрованные «микро‑заказы»?
+Отфильтрованные микро-заказы.
+*/