Докажите на SQL, что массовое обновление цен сделало ровно то, что задумано
Релизный скрипт поднял цены на 10% для одной категории:
UPDATE products SET price = price * 1.10 WHERE category_id = 7;
Таблица products_before — снимок products, снятый прямо перед запуском (те же id). Скрипт отчитался, что обновил 1 240 строк.
Напишите SQL, доказывающий, что обновление сделало ровно то, что задумано: изменилось нужное число строк, каждое новое значение верное, а вне категории 7 ничего не тронуто.
-- 1) сколько строк в целевой категории?
-- ваш запрос здесь
-- 2) есть ли в категории 7 строка, где новая цена не равна старой * 1.10?
-- ваш запрос здесь
-- 3) есть ли ВНЕ категории 7 строка, у которой цена изменилась?
-- ваш запрос здесьДопишите запросы.
Три запроса, а не один. Посчитайте строки в целевой категории и сравните с заявленным числом; соедините таблицу со снимком до запуска и убедитесь, что внутри категории нет строки с ценой, отличной от старой умноженной на 1.10; затем убедитесь, что вне категории не изменилась ни одна строка.
- ✗Считать число затронутых строк единственным доказательством
- ✗Проверять только строки в скоупе и не проверять, что остальное не изменилось
- ✗Выводить ожидаемые значения тем же оператором, который и внёс изменение
- →Как проверить обновление, если снимок таблицы не сняли?
- →Зачем оборачивать проверку в транзакцию с откатом?
Проверка состоит из трёх независимых утверждений — объём, значения и радиус поражения.
-- 1) объём: сколько строк в целевой категории (сравниваем с 1 240)
SELECT count(*) FROM products WHERE category_id = 7;
-- 2) значения: ни одной строки с неверной новой ценой
SELECT p.id, b.price AS old_price, p.price AS new_price
FROM products p
JOIN products_before b ON b.id = p.id
WHERE p.category_id = 7
AND p.price <> round(b.price * 1.10, 2);
-- 3) радиус поражения: вне категории 7 ничего не изменилось
SELECT p.id
FROM products p
JOIN products_before b ON b.id = p.id
WHERE p.category_id <> 7
AND p.price <> b.price;Запросы 2 и 3 обязаны вернуть ноль строк. Отдельно стоит проверить, что число строк в таблице не изменилось (UPDATE не должен ничего удалять или создавать), и что округление цены соответствует правилу, записанному в требованиях, а не тому, что случайно сделала СУБД.
