Кардинальность JOIN в SQL: как не умножить строки и выручку

Сигнал в данных

Почему после добавления таблицы событий сумма выручки стала в три раза больше?

JOIN часто выглядит как технический шаг, но он меняет зерно результата. Когда к заказу присоединяются позиции и события, одна исходная строка превращается в несколько, а SUM начинает складывать повторенные значения.

Если orders содержит одну строку на заказ, а order_items — несколько позиций, сначала агрегируй items до order_id. Только потом присоединяй сумму к orders и считай выручку.

Как устроен расчёт

Один ряд отчёта должен быть явно назван: заказ, пользователь, день или канал. Если SELECT смешивает поля разных уровней, сначала создай промежуточный слой с единым grain.

Проверь уникальность ключей обеих сторон, посчитай строки до и после соединения и добавь контрольную сумму. Для сложного запроса выдели каждый JOIN в отдельный CTE.

Если показатель строится по событиям, отдельно проверь повторную отправку, идентичность пользователя и часовой пояс. Если данные приходят из бизнес-системы, сопоставь техническое поле с тем, как команда реально принимает решение.

Практический сценарий

Если orders содержит одну строку на заказ, а order_items — несколько позиций, сначала агрегируй items до order_id. Только потом присоединяй сумму к orders и считай выручку.

Не копируй пример в рабочий отчёт вслепую. Сначала замени названия таблиц и полей, проверь кардинальность связей и запиши, какие строки должны попасть в результат. Хорошая адаптация сохраняет логику, но делает допущения видимыми.

WITH item_totals AS (\n  SELECT order_id, SUM(amount) AS item_revenue\n  FROM order_items\n  GROUP BY order_id\n)\nSELECT o.order_id, o.revenue, COALESCE(i.item_revenue, 0) AS item_revenue\nFROM orders AS o\nLEFT JOIN item_totals AS i USING (order_id);

Контрольные случаи

Опасны LEFT JOIN с фильтром правой таблицы в WHERE, соединение по неполному ключу и повторное присоединение уже размноженного CTE. Все три ошибки могут давать правдоподобные цифры.

Отдельно протестируй пустой результат, NULL, дубль, граничную дату и объект без связанной записи. Эти случаи не являются редкими исключениями: именно они чаще всего превращают рабочий показатель в красивую, но неверную цифру.

• Не смешивай зрелые и незрелые периоды без отдельной подписи.
• Не заменяй проверку качества тем, что запрос просто выполнился.
• Не делай причинный вывод из одного разреза.

Чтение визуализации

График здесь нужен не для украшения статьи. Он помогает увидеть форму сигнала: тренд, разрыв между сегментами, хвост распределения или этап, на котором теряется объект. Сначала прочитай оси и единицы, затем сравни с таблицей и только после этого формулируй вывод.

На визуализации «Как меняется число строк после JOIN» сравнивай не только максимальное значение. Проверь, одинаковы ли базы, не скрыта ли неполная дата и не меняется ли знаменатель от категории к категории.

Небольшое упражнение

Возьми пять заказов с разным числом позиций и вручную посчитай ожидаемую сумму. Сравни наивный JOIN и вариант с предварительной агрегацией.

После упражнения напиши вывод в двух версиях. Первая — техническая: какие строки и условия дали результат. Вторая — для команды: что изменилось, насколько это надёжно и какое действие стоит проверить. Если эти версии противоречат друг другу, вернись к определению показателя.

• Собери контрольный пример из пяти-десяти строк.
• Сверь итог с независимым способом расчёта.
• Проверь хотя бы один крайний случай.
• Зафиксируй дату, версию схемы и ограничение.

Что передать команде

Если задача требует факта на уровне заказа, агрегируй дочернюю таблицу до order_id. Если нужен анализ событий, не присоединяй денежный факт без отдельного контроля дублей.

Сильный аналитический материал не обещает абсолютной уверенности. Он показывает, как получить число, где оно может ошибиться и какое решение можно принять уже сейчас. Такой формат хорошо переносится в дашборд, SQL-тренажёр, собеседование и рабочее обсуждение с командой.