Какое утверждение про RIGHT JOIN верно в аналитических запросах?
A
A RIGHT JOIN B эквивалентен B LEFT JOIN A после перестановки таблиц местамиB
RIGHT JOIN исполняется быстрее LEFT JOIN на одних и тех же данных за счёт оптимизатораC
RIGHT JOIN снимает дубликаты по ключу соединения автоматически, как SELECT DISTINCTD
RIGHT JOIN представляет собой разновидность UNION ALL для двух таблиц без потерьПравильный ответ.
RIGHT JOIN — это симметричный вариант LEFT JOIN: меняете местами таблицы и получаете эквивалентный запрос.Разбор
По смыслу RIGHT JOIN сохраняет все строки из правой таблицы. Это эквивалентно LEFT JOIN, если переставить таблицы: A RIGHT JOIN B ↔ B LEFT JOIN A. Поэтому RIGHT JOIN часто избегают: он ухудшает читаемость, а функционально почти не даёт преимуществ.
Можно заниматься бесплатно
Готовим вопросы…
Три вопроса по теме этой страницы, с объяснениями.
Ещё вопросы по теме «JOIN и операции множеств»
- В отчёте нужно вывести всех пользователей и количество их заказов, включая тех, у кого заказов нет. Какой тип соединения между `users` и `orders` по `user_id` нужен?
- Нужно посчитать число пользователей, которые сделали хотя бы 1 заказ (таблицы `users(user_id)` и `orders(user_id, order_id)`). Какой запрос посчитает правильно?
- Вы соединили заказы с `order_items` и `payments` по `order_id`, а потом посчитали `SUM(paid_amount)`. Сумма оказалась завышенной. Что вероятнее всего произошло и как исправить?
- Есть две таблицы с одинаковой схемой: `events_web(user_id, event_name, created_at)` и `events_app(user_id, event_name, created_at)`. Нужно получить общий поток событий для дальнейшей агрегации. Что использовать?
- Нужно получить уникальный список идентификаторов пользователей из двух каналов: `campaign_a(user_id)` и `campaign_b(user_id)`. Как корректнее объединить списки, чтобы убрать дубликаты?
- Все вопросы по «JOIN и операции множеств» →