По какому признаку объединять таблицы в SQL

Что проверяют

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

Как отвечать

Начать с гранулярности: что такое одна строка слева и одна справа. Дальше по шагам:

• соединяем по полю, которое однозначно определяет строку справа: суррогатный id или внешний ключ, а не имя или почта, у текстовых полей плавают регистр и пробелы;
• если справа ключ не уникален, соединение размножит строки, и сумма по метрике вырастет. Проверять это надо до соединения;
• типы по обе стороны должны совпадать: скрытое приведение отключает индекс, а иногда и меняет результат сравнения;
• NULL не равен NULL, поэтому строки с пустым ключом исчезают из inner join. Если пустота значима, чинить явно через coalesce или is not distinct from;
• у медленно меняющихся измерений одного ключа мало, нужен ещё интервал действия версии, а для событий и временных рядов соединение по последнему известному значению на момент события;
• тип соединения выбирается из того, какая сторона обязательна: left, когда левая таблица задаёт состав выборки, inner, когда нужны обе.

Проверка уникальности занимает один запрос:

select user_id, count(*) from orders group by user_id having count(*) > 1;

Где спотыкаются

Не сверяют число строк до и после соединения. Дубль в справочнике размножает факты, среднее и сумма едут, а запрос при этом отрабатывает без единой ошибки.

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

Пишут условие по правой таблице в where, а не в on. Для left join это молча превращает его в inner: строки без пары отсеиваются проверкой на NULL, и половина выборки пропадает.