Репост из: Аналитика данных / Data Study
Из-за глупой ошибки в SQL компания чуть не потеряла 5 млн. и репутацию перед поставщиками
Наши действия при работе с данными напрямую влияют на конечные метрики в бизнес-отчетах. И любая ошибка аналитика может стать критичной
Из-за нехватки знаний и опыта аналитики допускают максимально глупые ошибки в конструкции CASE, которые критически могут менять метрики.
❌ пишут неправильный порядок условий
❌ не пишут ELSE
ЗАПОМНИ ЗОЛОТОЕ ПРАВИЛО ПОРЯДКА CASE УСЛОВИЙ
— ТАК ПИСАТЬ НЕПРАВИЛЬНО, ПОРЯДОК КРИВОЙ
SELECT
order_id,
CASE
WHEN status = 'confirmed' THEN 'подтвержден' — попадут все строки со статусом confirmed
WHEN status = 'confirmed' AND interface = 'app' THEN 'подтвержден через app' — не попадут никакие строки, потому что все учтутся в первом условии
END AS order_group
FROM orders
— ПИШИ ТАК, ОТ ЧАСТНОГО К ОБЩЕМУ. ДОБАВЬ ELSE ЧТОБЫ НЕ БЫЛО NULL, КОТОРЫЕ МОЖЕШЬ ПОТЕРЯТЬ НА ОТЧЕТЕ
SELECT
order_id,
CASE
WHEN status = 'confirmed' AND interface = 'app' THEN 'подтвержден через app' — попадут строки, которые подходят под комплексное условие по полям status и interface
WHEN status = 'confirmed' THEN 'подтвержден' — попадут все оставшиеся строки, которые не попали в первое условие, но у которых выполняется условие по status
ELSE 'не определена' — если не выполняется ни одно из условий, значит все остальные строки попадут сюда
END AS order_group
FROM orders
✅ Соблюдай порядок условий от частного к общему
✅ Указывай ELSE чтобы не поймать еще других проблем с NULL значениями, если условия не выполнились
➡️Если хочешь творить с данными магию с помощью SQL и выполнять бизнес-задачи любой сложности, приходи на курс "Продвинутый SQL и автоматизация витрин данных". Там разбираем как писать сложные аналитические запросы, оптимизировать их, проверять данные на качество и автоматизировать ETL процессы.
Запись в группу 27 июля
Наши действия при работе с данными напрямую влияют на конечные метрики в бизнес-отчетах. И любая ошибка аналитика может стать критичной
Из-за нехватки знаний и опыта аналитики допускают максимально глупые ошибки в конструкции CASE, которые критически могут менять метрики.
❌ пишут неправильный порядок условий
❌ не пишут ELSE
ЗАПОМНИ ЗОЛОТОЕ ПРАВИЛО ПОРЯДКА CASE УСЛОВИЙ
Условия указываются от частного к общему. CASE проверяет условия сверху вниз и останавливается на первом совпадении. Если сначала написать "заказы в статусе confirmed", а после "заказы в статусе confirmed и сделанные через app", то первое условие применится для всех строк, в том числе для тех заказов, которые попадают под второе более детальное условие
— ТАК ПИСАТЬ НЕПРАВИЛЬНО, ПОРЯДОК КРИВОЙ
SELECT
order_id,
CASE
WHEN status = 'confirmed' THEN 'подтвержден' — попадут все строки со статусом confirmed
WHEN status = 'confirmed' AND interface = 'app' THEN 'подтвержден через app' — не попадут никакие строки, потому что все учтутся в первом условии
END AS order_group
FROM orders
— ПИШИ ТАК, ОТ ЧАСТНОГО К ОБЩЕМУ. ДОБАВЬ ELSE ЧТОБЫ НЕ БЫЛО NULL, КОТОРЫЕ МОЖЕШЬ ПОТЕРЯТЬ НА ОТЧЕТЕ
SELECT
order_id,
CASE
WHEN status = 'confirmed' AND interface = 'app' THEN 'подтвержден через app' — попадут строки, которые подходят под комплексное условие по полям status и interface
WHEN status = 'confirmed' THEN 'подтвержден' — попадут все оставшиеся строки, которые не попали в первое условие, но у которых выполняется условие по status
ELSE 'не определена' — если не выполняется ни одно из условий, значит все остальные строки попадут сюда
END AS order_group
FROM orders
✅ Соблюдай порядок условий от частного к общему
✅ Указывай ELSE чтобы не поймать еще других проблем с NULL значениями, если условия не выполнились
➡️Если хочешь творить с данными магию с помощью SQL и выполнять бизнес-задачи любой сложности, приходи на курс "Продвинутый SQL и автоматизация витрин данных". Там разбираем как писать сложные аналитические запросы, оптимизировать их, проверять данные на качество и автоматизировать ETL процессы.
Запись в группу 27 июля