Dmitry Medvedev
61 lines
5.2 KiB
PL/PgSQL
61 lines
5.2 KiB
PL/PgSQL
--Задание 1. Оформление заказа
|
|
BEGIN;
|
|
|
|
INSERT INTO orders
|
|
(user_id, order_date, status)
|
|
VALUES
|
|
(10, '2025-01-15', 'paid');
|
|
|
|
INSERT INTO order_items
|
|
(order_id, product_id, quantity, price_at_purchase)
|
|
VALUES
|
|
(LASTVAL(), 6, 1, 4800),
|
|
(LASTVAL(), 7, 1, 5200);
|
|
|
|
UPDATE products
|
|
SET in_stock = FALSE
|
|
WHERE id IN (6, 7);
|
|
|
|
COMMIT;
|
|
|
|
/*Что в данных пойдёт не так, если часть шагов выполнится, а часть нет?
|
|
В таком случае транзакция не будет закрыта. Я начал бегин, но произошла ошибка внутри транзакции и поэтому dbeaver дальше ничего выполнять не будет пока я не сделаю откат, либо не скажу завершить.
|
|
|
|
Почему оформление заказа — типичный пример «либо всё, либо ничего»?
|
|
Потому что в этом случае происходят изменения записей сразу в нескольких таблицах одновременно. И либо меняются все значения, либо вообще ничего не меняется.
|
|
*/
|
|
|
|
--Задание 2. Ошибка посередине
|
|
/*- Сценарий:
|
|
- заказ создали;
|
|
- одну позицию заказа добавили;
|
|
- на второй позиции выяснилось, что товара нет на складе.
|
|
- Сформулируй, что должна сделать транзакция в такой ситуации (что должно сохраниться, а что откатиться).
|
|
|
|
ОТВЕТ: В таком случае все будет зависеть от бизнес-логики данного "магазина". Если отсутствие второго заказа является причиной для отклонения выполнения заказа, то должен быть откат.
|
|
А как по мне, то здесь правильным решением будет частичная запись без отката.
|
|
|
|
Какие «битые» заказы можно получить без отката (ROLLBACK)?
|
|
В таком случае можно получить: создан заказ, оплачен, а второго товара даже нет в наличие; появится неполный заказ с ошибками и это большая проблема.
|
|
|
|
Как такие ошибки повлияют на отчёты и витрины по выручке?
|
|
Такие ошибки могут криво влиять (будет искажаться информация) потому что заказ может быть оплачен, хотя его продать мы и не можем.
|
|
*/
|
|
|
|
--Задание 3. Один UPDATE как транзакция
|
|
/*- Возьми простое действие в магазине:
|
|
- смена `email` пользователя в `users`;
|
|
- изменение цены товара в `products`.
|
|
- Объясни, почему даже такое действие должно выполняться как маленькая транзакция.
|
|
|
|
ДАЖЕ ТАКОЕ МАЛЕНЬКОЕ ДЕЙСТВИЕ ДОЛЖНО ВЫПОЛНЯТЬСЯ ОТДЕЛЬНО ПОТОМУ ЧТО ОНО МОЖЕТ ВЛИЯТЬ НА ДРУГИЕ ПОКАЗАТЕЛИ В ДРУГИХ ТАБЛИЦАХ, СООТВЕТСТВЕННО МНОГОЕ МОЖЕТ СБИТЬСЯ.
|
|
ТАКЖЕ СТОИТ ПОНИМАТЬ, ЧТО ЧЕМ МЕНЬШЕ ДЕЙСТВИЙ В ТРАНЗАКЦИИ, ТЕМ ОНА ПРОЩЕ И ПОНЯТНЕЕ. ПРОЩЕ ОТКАТИТЬСЯ НАЗАД В ТАКОМ СЛУЧАЕ, ЧЕМ КОГДА ТРАНЗАКЦИЯ БОЛЬШАЯ.
|
|
**❓ Ответь на вопросы:**
|
|
|
|
|
|
- Что может случиться, если во время изменения цены пропадёт соединение с базой?
|
|
ЗДЕСЬ ЕСТЬ НЕСКОЛЬКО ВАРИАНТОВ, ЕСЛИ БЫЛ АВТОКОММИТ ИЛИ ОБЫЧНЫЙ КОММИТ. В ПЕРВОМ СЛУЧАЕ МОГЛА УСПЕТЬ ЗАВЕРШИТЬСЯ ТРАНЗАКЦИЯ НА СТОРОНЕ БД ИЛИ ДАЖЕ НЕ НАЧАТЬСЯ, О РЕЗУЛЬТАТЕ МЫ УЗНАЕМ ТОЛЬКО ЕСЛИ СДЕЛАЕМ СЕЛЕКТ, ЛИБО НЕ ЗАВЕРШИТЬСЯ И ОНА ОТКАТИТСЯ НА ПЕРВОНАЧАЛЬНОЕ СОСТОЯНИЕ. А ЕСЛИ БЫЛ ОБЫКНОВЕННЫЙ РУЧНОЙ КОММИТ, ТО ЗДЕСЬ ТАКЖЕ СТОИТ РАЗДЕЛЯТЬ НА ВЫПОЛНИЛСЯ ИЛИ НЕ ВЫПОЛНИЛСЯ КОММИТ (ЕСЛИ ДА, ТО ИЗМЕНЕНИЯ СОХРАНИЛИСЬ, ИНАЧЕ НЕТ).
|
|
|
|
- Почему хорошо, что база сама откатывает незавершённые изменения?
|
|
ПОТОМУ ЧТО ЕСЛИ БЫ ОНА НЕ ОТКАТЫВАЛА, ТО ЦЕЛОСТНОСТЬ ТРАНЗАКЦИИ НЕ СОБЛЮДАЛОСЬ БЫ, А ТРАНЗАКЦИЯ КАК РАЗ И НУЖНА ДЛЯ ЦЕЛОСТНОСТИ.
|
|
*/ |