2 changed files with 89 additions and 0 deletions
@@ -0,0 +1,56 @@
+--Задание 1. Оформление заказа
+BEGIN;
+
+INSERT INTO orders (user_id, order_date, status)
+VALUES (10, '2025-01-15', 'paid');
+
+INSERT INTO order_items (product_id, quantity, price_at_purchase)
+VALUES(6, 1, 4800), (7, 1, 5200);
+
+UPDATE products
+SET in_stock = TRUE
+WHERE id IN (6, 7);
+
+COMMIT;
+
+/*Что в данных пойдёт не так, если часть шагов выполнится, а часть нет?
+В таком случае транзакция не будет закрыта. Я начал бегин, но произошла ошибка внутри транзакции и поэтому dbeaver дальше ничего выполнять не будет пока я не сделаю откат, либо не скажу завершить.
+
+Почему оформление заказа — типичный пример «либо всё, либо ничего»?
+Потому что в этом случае происходят изменения записей сразу в нескольких таблицах одновременно. И либо меняются все значения, либо вообще ничего не меняется.
+*/
+
+--Задание 2. Ошибка посередине
+/*- Сценарий:
+    - заказ создали;
+    - одну позицию заказа добавили;
+    - на второй позиции выяснилось, что товара нет на складе.
+- Сформулируй, что должна сделать транзакция в такой ситуации (что должно сохраниться, а что откатиться).
+
+ОТВЕТ: В таком случае все будет зависеть от бизнес-логики данного "магазина". Если отсутствие второго заказа является причиной для отклонения выполнения заказа, то должен быть откат. 
+А как по мне, то здесь правильным решением будет частичная запись без отката. 
+
+Какие «битые» заказы можно получить без отката (ROLLBACK)?
+В таком случае можно получить: создан заказ, оплачен, а второго товара даже нет в наличие; появится неполный заказ с ошибками и это большая проблема.
+
+Как такие ошибки повлияют на отчёты и витрины по выручке?
+Такие ошибки могут криво влиять (будет искажаться информация) потому что заказ может быть оплачен, хотя его продать мы и не можем.
+*/
+
+--Задание 3. Один UPDATE как транзакция
+/*- Возьми простое действие в магазине:
+    - смена `email` пользователя в `users`;
+    - изменение цены товара в `products`.
+- Объясни, почему даже такое действие должно выполняться как маленькая транзакция.
+
+ДАЖЕ ТАКОЕ МАЛЕНЬКОЕ ДЕЙСТВИЕ ДОЛЖНО ВЫПОЛНЯТЬСЯ ОТДЕЛЬНО ПОТОМУ ЧТО ОНО МОЖЕТ ВЛИЯТЬ НА ДРУГИЕ ПОКАЗАТЕЛИ В ДРУГИХ ТАБЛИЦАХ, СООТВЕТСТВЕННО МНОГОЕ МОЖЕТ СБИТЬСЯ. 
+ТАКЖЕ СТОИТ ПОНИМАТЬ, ЧТО ЧЕМ МЕНЬШЕ ДЕЙСТВИЙ В ТРАНЗАКЦИИ, ТЕМ ОНА ПРОЩЕ И ПОНЯТНЕЕ. ПРОЩЕ ОТКАТИТЬСЯ НАЗАД В ТАКОМ СЛУЧАЕ, ЧЕМ КОГДА ТРАНЗАКЦИЯ БОЛЬШАЯ.
+**❓ Ответь на вопросы:**
+
+
+- Что может случиться, если во время изменения цены пропадёт соединение с базой?
+ЗДЕСЬ ЕСТЬ НЕСКОЛЬКО ВАРИАНТОВ, ЕСЛИ БЫЛ АВТОКОММИТ ИЛИ ОБЫЧНЫЙ КОММИТ. В ПЕРВОМ СЛУЧАЕ МОГЛА УСПЕТЬ ЗАВЕРШИТЬСЯ ТРАНЗАКЦИЯ НА СТОРОНЕ БД ИЛИ ДАЖЕ НЕ НАЧАТЬСЯ, О РЕЗУЛЬТАТЕ МЫ УЗНАЕМ ТОЛЬКО ЕСЛИ СДЕЛАЕМ СЕЛЕКТ, ЛИБО НЕ ЗАВЕРШИТЬСЯ И ОНА ОТКАТИТСЯ НА ПЕРВОНАЧАЛЬНОЕ СОСТОЯНИЕ. А ЕСЛИ БЫЛ ОБЫКНОВЕННЫЙ РУЧНОЙ КОММИТ, ТО ЗДЕСЬ ТАКЖЕ СТОИТ РАЗДЕЛЯТЬ НА ВЫПОЛНИЛСЯ ИЛИ НЕ ВЫПОЛНИЛСЯ КОММИТ (ЕСЛИ ДА, ТО ИЗМЕНЕНИЯ СОХРАНИЛИСЬ, ИНАЧЕ НЕТ).
+
+- Почему хорошо, что база сама откатывает незавершённые изменения?
+ПОТОМУ ЧТО ЕСЛИ БЫ ОНА НЕ ОТКАТЫВАЛА, ТО ЦЕЛОСТНОСТЬ ТРАНЗАКЦИИ НЕ СОБЛЮДАЛОСЬ БЫ, А ТРАНЗАКЦИЯ КАК РАЗ И НУЖНА ДЛЯ ЦЕЛОСТНОСТИ.
+*/
@@ -0,0 +1,33 @@
+-- 1. Задание 1: Анализ drop-off точек
+-- Используя conversion_funnel, найди курсы с самым большим процентом отвала между этапами enrolled → started (WHERE stage_name IN (...))
+SELECT 
+	course_id, 
+	stage_name,
+	conversion_from_previous,
+	conversion_from_start
+	
+	
+FROM conversion_funnel
+WHERE stage_name IN ('started');
+
+-- ОТВЕТ: Самые большие проценты отвала между enrolled и started замечены на курсе 1 и 3 (62 и 67% соответственно).
+
+-- 2. Задание 2: Топ-3 урока с повторными просмотрами
+-- Используя lesson_popularity_ranking, найди уроки, где avg_views_per_viewer > 1 (пользователи пересматривают)
+SELECT * FROM lesson_popularity_ranking
+WHERE avg_views_per_viewer > 1;
+
+--Ответ: Это урок 1 'select и from' и урок 4 'агрегации и group by', больше уроков нет с где avg_views_per_viewer > 1.
+
+-- 3. Задание 3: Лучшая когорта по retention
+-- Из user_cohort_analysis выбери месяц с максимальным retention_rate и проанализируй, почему (можно объединить с другими витринами)
+SELECT * FROM user_cohort_analysis;
+
+-- ОТВЕТ: По данному запросу это 2 когорты - январь и февраль 2023 года (по 75%).
+-- К сожалению, сейчас не могу понять с какими витринами можно ее объединить...
+
+
+-- 4. Задание 4: Анализ плана выполнения
+-- Запусти `EXPLAIN ANALYZE` на всех витринах. Найди узкие места: Seq Scan, высокие cost, JOIN без индексов, DISTINCT, подзапросы в SELECT.
+-- Перепиши запросы чтобы достигнуть минимального времени выполнения. 
+-- Напиши что сделал, почему, и насколько быстрее стал запрос