В одном отчёте вы считаете несколько метрик по событиям: dau, wau и число покупок. У всех метрик один и тот же фильтр: только продакшн-трафик и только выбранный период. Какой подход лучше защищает от ситуации, когда в одной метрике забыли часть фильтра?
AБазовый CTE
WITH base_events AS (...) с общим фильтром, от которого считаются все три метрикиBФильтр аккуратно скопирован в каждый подзапрос/CTE отдельно, чтобы метрики были независимы
CОтдельный подзапрос в
SELECT для каждой метрики, в каждом своя копия условия WHEREDМетрики считаются на сырых данных, а потом фильтр применяется к агрегированному результату
Правильный ответ. Общий базовый CTE через
WITH снижает риск расхождения бизнес-логики между метриками.Разбор
Когда общий фильтр (период, среда, исключения) повторяется, дублирование условий делает запрос хрупким: достаточно один раз забыть условие — и метрика станет несравнимой с остальными. Базовый CTE фиксирует единый набор событий, после чего каждую метрику можно считать отдельным шагом. Это повышает детерминизм и упрощает проверку: сначала валидируете base_events, затем сравниваете агрегаты.
Проверь себя · 1/3разбор после ответа
Дашборд содержит две метрики на одних и тех же продажах: топ товаров по выручке за период и общая выручка за тот же период. Витрина обновляется ежедневно, и важно, чтобы фильтр по периоду был один и тот же для обеих цифр. Какой подход надёжнее защищает от рассинхронизации?
Ещё вопросы по теме «Подзапросы и 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» →