Dmitry Medvedev
130 lines
7.3 KiB
SQL
130 lines
7.3 KiB
SQL
--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 гипотезы)?
|
||
Заниженная цена, неликвидность товара.
|
||
|
||
Что проще увидеть глазами: просто все заказы с суммой или именно отфильтрованные «микро‑заказы»?
|
||
Отфильтрованные микро-заказы.
|
||
*/ |