Почему возникает ошибка при SELECT * из двух таблиц с одинаковыми названиями колонок

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

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

Как отвечать

Начните с уточнения. Сам по себе select * из двух таблиц с одноимёнными колонками выполняется без ошибки: в выборке просто окажутся два столбца с именем id. Ошибка появляется там, где на такое имя ссылаются без указания таблицы:

select * from employees e, departments d where id = 1;
-- column reference "id" is ambiguous

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

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

Лечится это не хитростями, а дисциплиной: перечислять столбцы явно, давать псевдонимы вида e.id as employee_id, соединять таблицы через join ... on, а не перечислением в from, и отдавать наружу проекцию или DTO вместо сырой звёздочки.

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

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

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

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