Краткий ответ

Если одно и то же неуточнённое имя столбца существует в нескольких источниках запроса, SQL обычно завершает запрос ошибкой неоднозначности. Чтобы однозначно выбрать столбец, нужно обратиться к нему через имя таблицы или её псевдоним.

Исторический контекст

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

Правило обязательного уточнения защищает запрос от скрытого выбора «не того» столбца. Это особенно важно для ключей, дат и других часто повторяющихся имён.

Постановка проблемы

Предположим, две таблицы содержат столбец с одинаковым именем. Если в условии фильтра или списке выбора указать только это имя, СУБД не сможет однозначно определить источник значения.

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

Подробное решение

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

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

SELECT c.id, o.id
FROM customers AS c
JOIN orders AS o ON o.customer_id = c.id
WHERE c.id > 100;

В этом примере два столбца называются id, поэтому запись id была бы неоднозначной. Обращения c.id и o.id однозначно выбирают нужные столбцы.

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

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

Ситуация из практики

В отчёте объединили таблицы клиентов и заказов. В обеих таблицах есть id, а разработчик оставил неуточнённую ссылку на этот столбец в фильтре. Запрос не запустился из-за неоднозначности.

Рассматривались два варианта. Можно было переименовать столбцы в схеме, но это затрагивало бы существующие запросы и приложения. Можно было явно квалифицировать ссылки псевдонимами — этот вариант не менял модель данных и локально устранял ошибку.

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

Что кандидаты часто упускают

Что произойдёт, если столбец есть только в одном источнике, но его имя не квалифицировано?

Такая ссылка обычно допустима: SQL находит единственный подходящий столбец. Однако это не всегда лучший стиль — при последующем добавлении таблицы с таким же именем запрос может начать завершаться ошибкой. В сложных запросах квалификация всех значимых ссылок снижает риск регрессий.
Достаточно ли квалифицировать столбец только именем таблицы?

Если таблица используется в запросе под псевдонимом, обращаться к ней следует через этот псевдоним. Имя исходной таблицы и её псевдоним не являются двумя независимыми именами для свободного смешивания: псевдоним становится используемым обозначением источника в данном контексте. Поэтому согласованная форма вроде c.id надёжнее и лучше читается.
Меняется ли проблема неоднозначности при использовании вложенного запроса?

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