Вы считаете метрику: доля пользователей, которые совершили покупку в течение 7 дней после регистрации. Какой вариант построения запроса делает логику наиболее проверяемой и удобной для отладки?
AНаписать один огромный
SELECT с несколькими уровнями вложенных подзапросов без имён.BСделать коррелированный подзапрос в
SELECT, который сразу возвращает 0/1, и не выделять выборку покупок отдельно.CИспользовать
WITH только для финального результата, а фильтры по регистрациям и покупкам держать внутри одного подзапроса в FROM.DРазбить логику на несколько CTE, например
WITH signups AS (...), purchases AS (...), matched AS (...) SELECT ... FROM matched: так каждый шаг можно запускать и проверять отдельно.Правильный ответ. Многошаговый
WITH делает расчёт метрики похожим на пайплайн: каждый шаг имеет имя и понятную гранулярность.Разбор
Для метрик вроде конверсии важно контролировать уровни данных: 1 строка на пользователя в регистрациях, 1 строка на покупку в транзакциях, затем связка по user_id и окну времени. Когда каждый шаг оформлен как отдельный CTE, вы можете проверить объёмы и примеры данных на каждом этапе и быстрее найти, где появилась ошибка (неверная связь, лишние строки, неверный фильтр).
Проверь себя · 1/3разбор после ответа
В одном отчёте вы считаете несколько метрик по событиям:
dau, wau и число покупок. У всех метрик один и тот же фильтр: только продакшн-трафик и только выбранный период. Какой подход лучше защищает от ситуации, когда в одной метрике забыли часть фильтра?Ещё вопросы по теме «Подзапросы и CTE»
- В отчёте нужно посчитать выручку по странам пользователей только по оплаченным заказам за период. Какой подход обычно делает запрос более читаемым и позволяет переиспользовать шаг фильтрации?
- Вы выбираете пользователей, у которых есть хотя бы один платеж. В таблице `payments` поле `user_id` иногда бывает `NULL` (например, анонимные платежи). Почему в такой ситуации часто предпочитают `EXISTS`, а не `IN`?
- Вы пишете `SELECT u.user_id, (SELECT order_id FROM orders o WHERE o.user_id = u.user_id) AS last_order_id FROM users u`. Что может пойти не так и как исправить, чтобы подзапрос стал скалярным?
- Нужно выбрать заказы, у которых `amount` выше среднего `amount` по тому же пользователю. Какой вариант `WHERE` корректно использует коррелированный подзапрос?
- Вы готовите дашборд: нужно (1) топ товаров по выручке за период и (2) общая выручка за тот же период. Какой вариант снижает риск, что фильтр по периоду рассинхронизируется между расчётами?
- Все вопросы по «Подзапросы и CTE» →