При объединении двух выборок с одинаковыми именами столбцов, но разным порядком их перечисления, как SQL сопоставит значения в результирующих столбцах?
В операциях объединения выборок, таких как UNION, UNION ALL, INTERSECT и EXCEPT, столбцы сопоставляются по позиции, а не по имени. Поэтому одинаковые названия не защищают от ошибочного результата: значения из первой позиции одной выборки попадут к значениям из первой позиции другой.
Операции над множествами проектировались для работы с совместимыми наборами строк. Для этого SQL использует заранее определённую структуру результата: одинаковое количество позиций и совместимые типы данных в каждой позиции.
Имена столбцов не могут быть главным механизмом сопоставления, поскольку объединяемые запросы могут получать их из разных таблиц, использовать выражения или задавать разные псевдонимы. Поэтому стандартная модель опирается на порядок столбцов.
Ошибка возникает, когда два запроса возвращают логически одинаковые атрибуты, но перечисляют их в разной последовательности. SQL обычно не считает это ошибкой, если типы данных совместимы, и формирует корректный с точки зрения синтаксиса, но неверный с точки зрения бизнес-смысла результат.
Особенно опасен случай, когда позиции имеют совместимые типы, например идентификатор и код также представлены строками. Такой запрос выполнится успешно, а обнаружить проблему можно будет только при проверке данных.
Перед объединением нужно явно согласовать порядок выражений во всех выборках. Количество столбцов должно совпадать, а типы в соответствующих позициях — быть совместимыми по правилам конкретной СУБД.
Имена столбцов результирующего набора обычно берутся из первой выборки. Имена из последующих выборок не переименовывают соответствующие столбцы результата, но и не влияют на позиционное сопоставление.
UNION дополнительно устраняет дубликаты, а UNION ALL сохраняет все строки. Это отдельный вопрос от сопоставления столбцов: оба оператора всё равно сопоставляют позиции одинаковым способом.
В этом примере первый столбец результата будет содержать значения из customer_id первой выборки и из order_id второй. SQL не сопоставит столбцы по их именам.
Надёжная практика — явно приводить выражения к нужным типам и поддерживать одинаковый порядок атрибутов во всех частях объединения. Если запросы формируются динамически, порядок следует задавать централизованно, а не полагаться на порядок столбцов таблиц.
Отчёт объединял текущие и архивные заказы. В текущем источнике сначала выбирались идентификатор клиента и сумма заказа, а в архивном — сумма и идентификатор. Оба столбца имели числовые типы, поэтому запрос выполнился без ошибки, но суммы отображались как идентификаторы.
Рассматривались два варианта. Можно было исправить порядок только в одном месте отчёта, но это оставляло риск повторения ошибки при следующем изменении источника. Более надёжным решением стало явное описание единой схемы результата и приведение обеих выборок к этому порядку.
После исправления объединение стало устойчивым к внутренней структуре таблиц, а проверка типов и контрольные тесты обнаруживали нарушение контракта до публикации отчёта.
1. Влияют ли имена столбцов второй выборки на имена результата?
Обычно нет. Имена результирующих столбцов определяются первой выборкой объединения, поэтому псевдонимы во второй части не переименуют итоговые столбцы. При этом значения второй выборки всё равно попадут в позиции результата по порядку.
2. Достаточно ли одинакового количества столбцов для успешного объединения?
Нет. В каждой соответствующей позиции должны находиться совместимые типы данных. Даже при совместимости типов результат может быть логически ошибочным, если порядок атрибутов выбран неправильно.
3. Меняет ли UNION ALL правило сопоставления столбцов?
Нет. UNION ALL сохраняет дубликаты, но сопоставляет столбцы по позициям так же, как UNION. Различие между ними относится к обработке строк после формирования совместимого набора результатов, а не к структуре столбцов.