Нужно посчитать средний дневной доход: сначала SUM(amount) по каждому дню, затем AVG по дням. Какой запрос соответствует этой логике?
A
SELECT AVG(day_revenue) FROM (SELECT pay_date, SUM(amount) AS day_revenue FROM payments GROUP BY pay_date) d: два уровня агрегацииB
SELECT AVG(SUM(amount)) FROM payments GROUP BY pay_date: попытка вложить агрегат в агрегат напрямую без подзапросаC
SELECT AVG(amount) FROM payments: одно среднее по всем платежам без предварительной группировки по датеD
SELECT SUM(amount) / COUNT(*) FROM payments: сумма всех сумм делится на число всех строк без разреза по днямПравильный ответ. Для «агрегации над агрегацией» удобно вынести первый уровень в подзапрос в
FROM (или CTE), а затем агрегировать второй раз.Разбор
Средний дневной доход — это среднее по дням, а не среднее по платежам. Поэтому сначала нужно получить таблицу «день → выручка дня» (через GROUP BY pay_date), и только потом считать AVG по этим дневным суммам. Подзапрос в FROM делает уровни агрегации явными и уменьшает вероятность перепутать метрику. Вариант с AVG(SUM(...)) без подзапроса не работает; AVG(amount) и SUM/COUNT дают среднее по платежам, а не по дням.
Проверь себя · 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» →