Есть запрос.

ВЫБРАТЬ ПЕРВЫЕ 1
    Контрагенты.ИНН,
    Контрагенты.КПП,
    Контрагенты.ЮрФизЛицо,
    Контрагенты.Покупатель,
    Контрагенты.Поставщик,
    КонтактнаяИнформация.Представление КАК ЮрАдрес
ИЗ
    РегистрСведений.КонтактнаяИнформация КАК КонтактнаяИнформация
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты
        ПО ((ВЫРАЗИТЬ(КонтактнаяИнформация.Объект КАК Справочник.Контрагенты)) = Контрагенты.Ссылка)
            И (Контрагенты.Ссылка = &Контрагент)
            И (КонтактнаяИнформация.Вид = ЗНАЧЕНИЕ(Справочник.ВидыКонтактнойИнформации.ЮрАдресКонтрагента))

Работает.
Но вот если внутреннее соединение заменить на левое, то результат совсем другой.

Вопрос. Так и должно быть в классике, или это особенность реализации запросов в 1С?

"результат совсем другой. "

Он тебе ВойнуИМир в ответ выдаёт?

(1) Нет, он дает Null по полю ЮрАдрес.

(0) всё правильно, результаты не должны совпадать

(2) И ши ви таки хочите иного?

(0) Так и должно быть по классике. Если под классикой понимать здравый смысл и формальную логику.

(3) левое  - справа есть null - выводим
внутреннее - справа есть null - не выводим

Если убрать "Первые 1", то результаты будут идентичными.

Выразить в Соединении - вселенское зло и пичаль

тьфу...
Не тот запрос скопировал :(

ВЫБРАТЬ
    Контрагенты.ИНН,
    Контрагенты.КПП,
    Контрагенты.ЮрФизЛицо,
    Контрагенты.Покупатель,
    Контрагенты.Поставщик,
    КонтактнаяИнформация.Представление КАК ЮрАдрес
ИЗ
    Справочник.Контрагенты КАК Контрагенты
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.КонтактнаяИнформация КАК КонтактнаяИнформация
        ПО ((ВЫРАЗИТЬ(КонтактнаяИнформация.Объект КАК Справочник.Контрагенты)) = Контрагенты.Ссылка)
            И (Контрагенты.Ссылка = &Контрагент)
            И (КонтактнаяИнформация.Вид = ЗНАЧЕНИЕ(Справочник.ВидыКонтактнойИнформации.ЮрАдресКонтрагента))


(8) Так советует Заратустра от ИТС 1С.

все... вопрос снимается. Сам туплю.

(10) не верю. Использование Выразить рекомендуется в других случаях, я именно про Соединение, там это зло

(12) Правильно что не веришь. Видимо у меня устарела информация. Сейчас статьи не нашел.
Вопрос - где можно почитать почему не рекомендуется в соединениях использовать Выразить?

(13) да просто посмотри в профайлере во что превращается сие богомерзкое дело...
На курсах по запросам об этом прямо говорят преподы обычно

(14) Понял. Спасибо!

(14) И во что же? Я, наивный, почему-то считал, что просто добавляется условие на тип. Нет?

(16) щас точно не скажу, толи индекс скан станет идти, толи целая портянка условий... короче плохо, сталкивался. убрав в одном запросе такое выразить - скорость выполнения на порядочек скакнула. Скуля под рукой нет

Подумав... Скорее всего да - ничего хорошего не будет.
В соединениях использовать ВЫРАЗИТЬ() в самом деле бессмысленно.

частично по теме http://programmist1s.ru/ekspert-optimizatsiya-zaprosov-v-1s/
без выразить правда, но есть моменты типа использования ИЛИ, и соединения с вложенным запросом

(19) С вложенными подзапросами - момент спорный. Всё сильно зависит от условий.

(17) Индекс скан? Точно не индекс сиик?
А если найду?

(21) не точно, я ж сказал - щас точно не скажу :)
Ну ты хоть согласен что это ЗЛО?

(20) там проблема с постоением плана запроса, мол скулю сложно в этом случае определить оптимальный план, и может (не всегда конечно) выбрать неоптимальный

(22) Я согласен, что запрос - шлак.
И что это - не ДОБРО точно.

(23) Я за все время только 1 раз сталкивался с неоптимальным планом, связанным с конструкцией EXIST (условие по вложенному запросу).

(25) если есть вероятность выбора неоптимального плана - то зачем её допускать, если есть простой способ обхода? я хз, у меня уже просто рефлекс выработался, не пишу соединения со вложенными, сразу ВТ делаю

конечно если во вложенном всего 5-10 записей всегда - то и он сойдёт, это мелочи

(26) т.е. оптимальней кидать во временную с полем Выразить() и потом соединять с ним, чем соединять с условием Выразить()?

(28) нет, оптимальней просто соединять, без Выразить.
Про временную - это когда используются вложенные запросы

(26) Используя напропалую временные таблицы ты лишаешь оптимизатор запроса свободы при построении плана плюс получаешь лишние накладные расходы. Это далеко не то же самое, что уменьшить "вероятность выбора неоптимального плана".
Лично я использую временные таблицы только в самых явных случаях (многократное использование полученных данных, например). А дальше экспериментирую только если производительность не устраивает. И выигрыш при создании временных таблиц я получаю нечасто.

(25), (26), (30) - еретическая мысль, в запросах можно использовать виртуальные т. Почему бы их не сделать методами платформы, а не запроса ?

Хы... Вот так глупость утром спросишь. Поймешь что глупость спросил.А к обеду много нового узнаешь :)
Обожаю мисту.

(31) Т.е. ты предлагаешь сделать то же самое, только хуже? И какой в этом смысл?
На уровне СУБД это будет тот же самый запрос. Только ты не сможешь его использовать как составляющую более сложного запроса.

Да и сделано уже всё. Методами прикладных объектов ты можешь выбрать практически то же самое, что и голыми виртуальными таблицами этих объектов. Только так никто не делает, потому что глупо.

(34) нужно работать "Методами прикладных объектов". Глупо работать запросами (от этого только "растопыривание пальцеВ").

(35) Учи запросы, глупыш упрямый.