From 204913caa884147cced93351507e1ff44097cc57 Mon Sep 17 00:00:00 2001 From: Dmitry Medvedev Date: Thu, 28 May 2026 21:00:11 +0500 Subject: [PATCH] add 8 tasks with agregation sql --- dmedvedev/agregation.sql | 130 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 dmedvedev/agregation.sql diff --git a/dmedvedev/agregation.sql b/dmedvedev/agregation.sql new file mode 100644 index 0000000..7e83f4d --- /dev/null +++ b/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 гипотезы)? +Заниженная цена, неликвидность товара. + +Что проще увидеть глазами: просто все заказы с суммой или именно отфильтрованные «микро‑заказы»? +Отфильтрованные микро-заказы. +*/ \ No newline at end of file