Вы считаете метрику: доля пользователей, которые совершили покупку в течение 7 дней после регистрации. Какой вариант построения запроса делает логику наиболее проверяемой и удобной для отладки?
AОдин большой
SELECT с несколькими уровнями вложенных подзапросов без отдельных имён шаговBКоррелированный подзапрос в
SELECT, возвращающий 0/1 на пользователя без выделения покупокCФинальный
WITH, в котором фильтры по регистрациям и покупкам собраны в одном подзапросе в FROMDОтдельные CTE:
WITH signups AS (...), purchases AS (...), matched AS (...) с проверкой каждого шагаПравильный ответ. Многошаговый
WITH делает расчёт метрики похожим на пайплайн: каждый шаг имеет имя и понятную гранулярность.Разбор
Для метрик вроде конверсии важно контролировать уровни данных: одна строка на пользователя в регистрациях, одна строка на покупку в транзакциях, затем связка по user_id и окну времени. Когда каждый шаг оформлен как отдельный CTE, вы можете проверить объёмы и примеры данных на каждом этапе и быстрее найти, где появилась ошибка (неверная связь, лишние строки, неверный фильтр). Большой вложенный запрос трудно отлаживать; коррелированный подзапрос смешивает уровни; один подзапрос в FROM не даёт промежуточных проверок.
Проверь себя · 1/3разбор после ответа
Вы считаете метрику: доля пользователей, которые совершили покупку в течение 7 дней после регистрации. Какой вариант построения запроса делает логику наиболее проверяемой и удобной для отладки?
Ещё вопросы по теме «Подзапросы и 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` корректно использует коррелированный подзапрос?
- Дашборд содержит две метрики на одних и тех же продажах: топ товаров по выручке за период и общая выручка за тот же период. Витрина обновляется ежедневно, и важно, чтобы фильтр по периоду был один и тот же для обеих цифр. Какой подход надёжнее защищает от рассинхронизации?
- Все вопросы по «Подзапросы и CTE» →