From 32041e1233e8d82cc2cd3bdd7fa615a893db606f Mon Sep 17 00:00:00 2001 From: Dmitry Medvedev Date: Fri, 26 Jun 2026 00:55:31 +0500 Subject: [PATCH] added files with transactions and 1 part of pet project (additional tasks) --- dmedvedev/10.1.Transactions.sql | 56 +++++++++++++++++++ .../11.7 Pet Project Additional tasks.sql | 33 +++++++++++ 2 files changed, 89 insertions(+) create mode 100644 dmedvedev/10.1.Transactions.sql create mode 100644 dmedvedev/11.7 Pet Project Additional tasks.sql diff --git a/dmedvedev/10.1.Transactions.sql b/dmedvedev/10.1.Transactions.sql new file mode 100644 index 0000000..366d994 --- /dev/null +++ b/dmedvedev/10.1.Transactions.sql @@ -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`. +- Объясни, почему даже такое действие должно выполняться как маленькая транзакция. + +ДАЖЕ ТАКОЕ МАЛЕНЬКОЕ ДЕЙСТВИЕ ДОЛЖНО ВЫПОЛНЯТЬСЯ ОТДЕЛЬНО ПОТОМУ ЧТО ОНО МОЖЕТ ВЛИЯТЬ НА ДРУГИЕ ПОКАЗАТЕЛИ В ДРУГИХ ТАБЛИЦАХ, СООТВЕТСТВЕННО МНОГОЕ МОЖЕТ СБИТЬСЯ. +ТАКЖЕ СТОИТ ПОНИМАТЬ, ЧТО ЧЕМ МЕНЬШЕ ДЕЙСТВИЙ В ТРАНЗАКЦИИ, ТЕМ ОНА ПРОЩЕ И ПОНЯТНЕЕ. ПРОЩЕ ОТКАТИТЬСЯ НАЗАД В ТАКОМ СЛУЧАЕ, ЧЕМ КОГДА ТРАНЗАКЦИЯ БОЛЬШАЯ. +**❓ Ответь на вопросы:** + + +- Что может случиться, если во время изменения цены пропадёт соединение с базой? +ЗДЕСЬ ЕСТЬ НЕСКОЛЬКО ВАРИАНТОВ, ЕСЛИ БЫЛ АВТОКОММИТ ИЛИ ОБЫЧНЫЙ КОММИТ. В ПЕРВОМ СЛУЧАЕ МОГЛА УСПЕТЬ ЗАВЕРШИТЬСЯ ТРАНЗАКЦИЯ НА СТОРОНЕ БД ИЛИ ДАЖЕ НЕ НАЧАТЬСЯ, О РЕЗУЛЬТАТЕ МЫ УЗНАЕМ ТОЛЬКО ЕСЛИ СДЕЛАЕМ СЕЛЕКТ, ЛИБО НЕ ЗАВЕРШИТЬСЯ И ОНА ОТКАТИТСЯ НА ПЕРВОНАЧАЛЬНОЕ СОСТОЯНИЕ. А ЕСЛИ БЫЛ ОБЫКНОВЕННЫЙ РУЧНОЙ КОММИТ, ТО ЗДЕСЬ ТАКЖЕ СТОИТ РАЗДЕЛЯТЬ НА ВЫПОЛНИЛСЯ ИЛИ НЕ ВЫПОЛНИЛСЯ КОММИТ (ЕСЛИ ДА, ТО ИЗМЕНЕНИЯ СОХРАНИЛИСЬ, ИНАЧЕ НЕТ). + +- Почему хорошо, что база сама откатывает незавершённые изменения? +ПОТОМУ ЧТО ЕСЛИ БЫ ОНА НЕ ОТКАТЫВАЛА, ТО ЦЕЛОСТНОСТЬ ТРАНЗАКЦИИ НЕ СОБЛЮДАЛОСЬ БЫ, А ТРАНЗАКЦИЯ КАК РАЗ И НУЖНА ДЛЯ ЦЕЛОСТНОСТИ. +*/ \ No newline at end of file diff --git a/dmedvedev/11.7 Pet Project Additional tasks.sql b/dmedvedev/11.7 Pet Project Additional tasks.sql new file mode 100644 index 0000000..39dec6c --- /dev/null +++ b/dmedvedev/11.7 Pet Project Additional tasks.sql @@ -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. +-- Перепиши запросы чтобы достигнуть минимального времени выполнения. +-- Напиши что сделал, почему, и насколько быстрее стал запрос \ No newline at end of file