Студия управления SQL Server 2008 не проверяет синтаксис моего запроса

Question

Как всегда, для моего удивления будет разумное объяснение, но до тех пор ....

У меня есть этот запрос

delete from Photo  where hs_id  in (select hs_id  from HotelSupplier where id = 142)

, который выполняется просто отлично (позже я нашелвышло, что вся таблица фотографий была пуста)

но странная вещь: в HotelSupplier нет поля hs_id, оно называется hs_key!

Поэтому, когда я выполняю последнюю часть

select hs_id  from HotelSupplier where id = 142

отдельно (выберите эту часть запроса мышью и нажмите F5), я получаю сообщение об ошибке, но когда я использую его в предложении in, это не так!

Интересно, это нормальное поведение?

Answer 1

Он принимает значение hs_id из внешнего запроса.

Совершенно верно иметь запрос, который не проецирует ни одного столбца из выбранной таблицы в списке select.

Например,

select 10 from HotelSupplier where id = 142

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

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

Результатом этого запроса будет удаление всех строк из Photo, где hs_id не равно нулю, если в HotelSupplier есть хотя бы одна строка, где id = 142 (и поэтому подзапрос возвращает хотя бы однустрока)

Возможно, будет немного понятнее, если учесть, каков эффект от этого

delete from Photo  where Photo.hs_id  in (select Photo.hs_id)

Это, конечно, эквивалентно

delete from Photo where Photo.hs_id = Photo.hs_id

Кстатиэто, безусловно, самая распространенная «ошибка», о которой я лично ошибочно сообщал в Microsoft Connect.Эрланд Соммарског включает его в свой список желаний 1027 * для SET STRICT_CHECKS ON

Answer 2

Это сильный аргумент для сохранения согласованности имен столбцов между таблицами. Как говорит @Martin, синтаксис SQL позволяет разрешать имена столбцов из внешнего запроса, если во внутреннем запросе нет совпадений. Это благо при написании коррелированных подзапросов, но иногда может сбить вас с толку (как здесь)