Для одного order_id в order_items есть 3 строки, а в payments есть 2 строки. Вы соединили всё в одну таблицу по order_id без предварительной агрегации. Сколько строк получится для этого заказа и почему?
A5 строк, потому что 3 + 2
B3 строки, потому что это
one-to-manyC6 строк, потому что возникает
many-to-many и join explosion: 3 * 2D2 строки, потому что платежи «поглощают» позиции
Правильный ответ. Когда две таблицы обе
one-to-many к одному ключу, их JOIN превращается в many-to-many и даёт join explosion.Разбор
Внутри одного order_id позиции и платежи комбинируются между собой. Каждая из 3 позиций соединится с каждым из 2 платежей, поэтому получится 6 строк. Это типичный источник duplication в денежных метриках, если затем делать SUM().
Проверь себя · 1/3разбор после ответа
Вы соединяете
users и orders по user_id, где у пользователя может быть много заказов (one-to-many). Как посчитать число пользователей, которые сделали хотя бы один заказ, чтобы избежать duplication?Ещё вопросы по теме «JOIN и кардинальность»
- В таблице `users` 100 000 строк, в таблице `user_profiles` — ровно одна строка на каждого `user_id`. Вы делаете `INNER JOIN` по `user_id`. Что верно про число строк результата?
- Вы соединяете `users` и `orders` по `user_id`, где у пользователя может быть много заказов (`one-to-many`). Как посчитать число пользователей, которые сделали хотя бы один заказ, чтобы избежать `duplication`?
- Нужен датасет на уровне `user_id`: выручка из `orders` и число сессий из `sessions`. В обеих таблицах по пользователю много строк (`one-to-many`). Какой подход минимизирует риск `join explosion`?
- Вы хотели посчитать средний чек по заказам как `AVG(order_total)`. Но перед этим соединили `orders` с `order_items` по `order_id` (`one-to-many`). Почему `AVG()` может измениться по сравнению с расчётом на таблице `orders`?
- В каком случае `SUM(order_amount)` после `JOIN` скорее всего останется корректным, без эффекта `duplication`?
- Все вопросы по «JOIN и кардинальность» →