Суммы после JOIN чаще всего увеличиваются потому, что одна сделка соединяется с несколькими дочерними строками. Если затем сложить сумму сделки, она повторится для каждой строки результата. Исправление начинается с определения зерна таблиц — того, какой объект или событие представляет одна строка.
Опишите зерно до запроса
В таблице сделок одна строка может соответствовать сделке, в платежах — отдельной операции, в задачах — действию менеджера. Соединение этих таблиц не сохраняет автоматически зерно сделки. Итоговый набор может стать комбинацией платежа и задачи внутри неё.
Для каждого источника укажите уникальный ключ и ожидаемую кратность связи. Проверяйте уникальность фактическими данными, а не названием столбца. Поле deal_id в таблице событий обозначает связь со сделкой, но не обязано быть уникальным ключом этой таблицы.
Условный пример умножения строк
Предположим, сделка имеет сумму 100 условных денежных единиц, два платежа на 40 и 60 и три задачи. Прямое соединение всех таблиц по сделке даст шесть сочетаний. Сумма сделки в таком результате станет 600, а каждый платёж повторится трижды.
Количество уникальных сделок при этом останется равным одному. Поэтому корректный COUNT DISTINCT не доказывает корректность суммы. Аналитик должен проверить отдельно число строк, число уникальных объектов и денежные показатели на каждом шаге соединения.
Агрегируйте дочерние данные заранее
Если отчёту нужна одна строка на сделку, платежи сначала сворачивают до сделки, получая общую оплату. Задачи отдельно сворачивают до нужных признаков: количество, ближайшая дата или число просроченных. Затем эти подготовленные наборы соединяют с таблицей сделок.
Такой подход сохраняет смысл расчётов, но требует аккуратных фильтров. Например, оплата за месяц и задачи за всю историю относятся к разным временным выборкам. Периоды нужно назвать в показателях и описании запроса, иначе технически правильная агрегация даст непонятный управленческий результат.
Не лечите проблему случайным DISTINCT
Удаление одинаковых строк может скрыть симптом и одновременно убрать реальные операции. Два платежа одинаковой суммы — не обязательно дубль. DISTINCT по сумме особенно опасен: он смешивает разные события, если их значения совпали.
Иногда отчёт действительно должен иметь зерно платежа или товарной позиции. Тогда сумму сделки нельзя просто суммировать по строкам. Нужна отдельная мера на правильном уровне либо обоснованное распределение суммы. Правило распределения согласуют с владельцем показателя и проверяют на частичных оплатах и возвратах.
Проверьте фильтры и неизвестные связи
Условия на дочернюю таблицу после соединения могут исключить сделки без платежей или задач. Это меняет воронку: отсутствие события становится причиной исчезновения исходного объекта. Отдельно испытайте карточки без дочерних строк и записи с неизвестным ключом.
Не подменяйте отсутствующий платёж нулём до выяснения полноты загрузки. Ноль означает известное отсутствие оплаты, а пустое значение может означать неизвестный результат. Управленческий контекст показателей приведён в статье об отчёте продаж из CRM.
Минимальная программа сверки
Создайте контрольный набор: сделка без платежей, сделка с одним платежом, сделка с несколькими одинаковыми платежами и сделка с возвратом. Для каждой вручную запишите ожидаемую сумму и число объектов.
После каждого JOIN сравните число строк и уникальных ключей, затем денежные итоги. Приёмка успешна, когда появление дополнительной задачи не меняет выручку, а новый платёж меняет её ровно по установленному правилу. Сохраните этот набор вместе с заданием: он поможет обнаружить регрессию при добавлении следующей таблицы.
Применить в вашей компании
Обсудим вашу задачу?
Поможем разобраться с процессом, данными и настройками. Работаем удалённо с компаниями по всей России.