В таблице orders 120 строк (по одной на order_id). В order_items ровно по 3 строки на каждый order_id. Сколько строк будет после соединения orders с order_items по order_id и почему?
AБудет 120 строк, потому что
JOIN по order_id не должен менять число строк левой таблицыBБудет 480 строк, потому что результат
JOIN равен сумме строк двух таблиц: 120 плюс 360CБудет 360 строк, потому что это соединение
один-ко-многим и каждой строке orders соответствует 3 строки в order_itemsDБудет 3 строки, потому что в каждом заказе ровно три позиции и
JOIN сворачивает их в строки заказаПравильный ответ. При соотношении
один-ко-многим после JOIN количество строк обычно становится равным числу строк в «многой» стороне.Разбор
Каждая строка из orders соединится с 3 строками из order_items, поэтому получится 120 * 3 = 360 строк. Это нормальное поведение для соотношения один-ко-многим и не является ошибкой само по себе. Ошибка появляется, если после такого JOIN считать метрики, которые должны быть на уровне заказа, без учёта дублирования строк.
Проверь себя · 1/3разбор после ответа
Вы считаете «уникальные покупатели по бренду». Данные:
order_items(user_id, product_id) и products(product_id, brand). Один пользователь может купить несколько товаров одного бренда. Какой расчёт на объединённых данных соответствует цели и устойчив к дублированию строк?Ещё вопросы по теме «JOIN и кардинальность»
- В таблице `users` 100 000 строк, в таблице `user_profiles` — ровно одна строка на каждого `user_id`. Вы делаете `INNER JOIN` по `user_id`. Что верно про число строк результата?
- Вы соединяете таблицы пользователей и заказов по `user_id`, где у одного пользователя может быть много заказов (связь «один ко многим»). Как посчитать число пользователей, которые сделали хотя бы один заказ, и не получить дубли?
- Для одного `order_id` в `order_items` есть 3 строки, а в `payments` — 2 строки. Вы соединили обе таблицы по `order_id` без предварительной агрегации. Сколько строк получится для этого заказа и почему?
- Нужен набор данных на уровне `user_id`: выручка из `orders` и число сессий из `sessions`. В обеих таблицах по пользователю много строк (один-ко-многим). Какой подход минимизирует риск размножения строк в соединении?
- Вы хотели посчитать средний чек по заказам как `AVG(order_total)`. Но перед этим соединили `orders` с `order_items` по `order_id` (связь один-ко-многим). Почему `AVG()` может измениться по сравнению с расчётом на таблице `orders`?
- Все вопросы по «JOIN и кардинальность» →