Запрос упростил для понятности, на самом деле он гораздо больше.
Первый вариант:
ВЫБРАТЬ
   ПриходнаяТТН.Номер,
   ПриходнаяТТНТовары.Товар КАК Номенклатура
ИЗ
   Документ.ПриходнаяТТН.ТЧасть КАК ПриходнаяТТНТовары
       ЛЕВОЕ СОЕДИНЕНИЕ Документ.ПриходнаяТТН КАК ПриходнаяТТН
       ПО ПриходнаяТТНТовары.Ссылка = ПриходнаяТТН.Ссылка
ГДЕ
   ПриходнаяТТН.Дата МЕЖДУ &НачПериода И &КонПериода

Второй:
ВЫБРАТЬ
   ПриходнаяТТН.Номер,
   ПриходнаяТТНТовары.Товар КАК Номенклатура
ИЗ
   Документ.ПриходнаяТТН.ТЧасть КАК ПриходнаяТТНТовары
       ЛЕВОЕ СОЕДИНЕНИЕ Документ.ПриходнаяТТН КАК ПриходнаяТТН
       ПО ПриходнаяТТНТовары.Ссылка = ПриходнаяТТН.Ссылка
ГДЕ
   ПриходнаяТТН.Дата МЕЖДУ &НачПериода И &КонПериода
   И ПриходнаяТТНТовары.Ссылка.Дата МЕЖДУ &НачПериода И &КонПериода

Третий:
ВЫБРАТЬ
   ПриходнаяТТНТовары.Ссылка.Номер,
   ПриходнаяТТНТовары.Товар КАК Номенклатура
ИЗ
   Документ.ПриходнаяТТН.ТЧасть КАК ПриходнаяТТНТовары
ГДЕ
   ПриходнаяТТНТовары.Ссылка.Дата МЕЖДУ &НачПериода И &КонПериода

В первом варианте не левое, а внутреннее
Третий в любом случае будет скулем преобразован в первый
Второй чушь, имхо

Точно в первом внутреннее? Мне такой запрос поставщик дал как образец.

Третий точно будет не дольше чем первый? Не будет на каждую запись из ТЧ выбираться каждый раз заново запись из таблицы документов? 100%?

И чем второй плох? Дополнительный отбор по дате не уменьшит количество выбранных во второй таблице записей и не ускорит?

При обращении ПриходнаяТТНТовары.Ссылка.Дата скуль добавит соединение с таблицей Документ.ПриходнаяТТН. Т.е. первый вариант - это просто вариант, который в явном виде даст скулю понять, что нужно сделать.

Во втором варианте на Документ.ПриходнаяТТН дважды накладывается одно и то же условие. Зачем?

(4) А если выбирать не только ПриходнаяТТНТовары.Ссылка.Номер, но и ПриходнаяТТНТовары.Ссылка.Клиент, и ПриходнаяТТНТовары.Ссылка.Склад, и другие поля, скуль не будет на каждое поле добавлять соединение с таблицей  Документ.ПриходнаяТТН?

Во втором варианте условие накладывается на разные выборки. Как если бы выбрали из таблицы Документ.ПриходнаяТТН два раза с разными условиями. Я же во втором условии могу другие даты указать.

(0) смотри планы запросов и все понятно будет.

(6) это не ответ.

Короче нужно использовать третий вариант и не париться?

(8) первый вариант рабочий в том случае, когда тебе надо выбрать шапку документа, а тч дока пустая!

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


Поэтому тут вопрос в том, как это применять!

(8) ток я бы опять таки поменял местами Табличы в первом запросе. Т.е. не шапку к ТЧ цеплял ,а наоборот ТЧ к шапке.

(10) То есть правое соединение?

(7) это нормальный подход специалиста.

(11) если сделаешь в конструкторе, то система все-равно перекрутит все на левое соединение!

А вообще я же уже сказал - тут все зависит от задачи!
Нужна тебе шапка без в случае пустой ТЧ это один запрос. Нужна шапка ТОЛЬКО при наличии заполненой ТЧ это другой запрос.

А еще может быть шапка + 2 объединенные ТЧ (например товары и услуги) - это уже третий запрос!

(12) Вопрос задан конкретный, а ответ не по теме. Я же не спрашивал "Как мне научиться правильно работать?"

1) Смотря от задачи как (13) сказал.
2) Имхо, бред
3) То же что и 1) только он преобразуется во внутренее соединение.
И кстати по возможности лучше делать левое (если это не противоречит логике алгоритма) чем внутреннее.

(13) Если в конструкторе, то да.
Мне нужна шапка ТОЛЬКО при наличии заполненой ТЧ. Но вопрос в том, как на быстродействии отразится то что я во втором запросе сделал дополнительное условие на вторую таблицу.
А в третьем таблицу документов выбираю через тчасть, это не увеличит выборку реквизитов документа если в тчасть будет много записей?

(3) 3-й вариант даже быстрее первого может быть, ведь в его случае гарантированно сработает оптимизация, т.к. система знает, что ты от нее хочешь. Особенно это заметно будет в случае километровых запросов, когда автооптимизация может и не сработать после определенного предела косяков.

(12) Специалист не надеется на какие-то планы, которые, к тому же, могут поменяться как при обновлении платформы, так и при обновлении SQL.

А вообще, 1-й вариант лучше делать так:


ВЫБРАТЬ
   ПриходнаяТТН.Номер,
   ПриходнаяТТНТовары.Товар КАК Номенклатура
ИЗ
   Документ.ПриходнаяТТН.ТЧасть КАК ПриходнаяТТНТовары
       ЛЕВОЕ СОЕДИНЕНИЕ
   (ВЫБРАТЬ
       Ссылка,
       Номер
   ИЗ
       Документ.ПриходнаяТТН КАК ПриходнаяТТН
   ГДЕ
       ПриходнаяТТН.Дата МЕЖДУ &НачПериода И &КонПериода
   )  КАК ПриходнаяТТН
       ПО ПриходнаяТТНТовары.Ссылка = ПриходнаяТТН.Ссылка


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

А при большой выборке (когда запрос хотя бы секунду исполняется) будет лучше


ВЫБРАТЬ
   Ссылка,
   Номер
ПОМЕСТИТЬ ВТДокументы
ИЗ
   Документ.ПриходнаяТТН КАК ПриходнаяТТН

ГДЕ
   ПриходнаяТТН.Дата МЕЖДУ &НачПериода И &КонПериода
;

ВЫБРАТЬ
   ПриходнаяТТН.Номер,
   ПриходнаяТТНТовары.Товар КАК Номенклатура
ИЗ
   Документ.ПриходнаяТТН.ТЧасть КАК ПриходнаяТТНТовары
   ЛЕВОЕ СОЕДИНЕНИЕ ВТДокументы КАК ПриходнаяТТН
   ПО ПриходнаяТТН.Ссылка = ПриходнаяТТНТовары.Ссылка

ГДЕ
   ПриходнаяТТНТовары.Ссылка В (ВЫБРАТЬ Ссылка ИЗ ВТДокументы)


Оговорка про большую выборку связана с тем, что создание временной таблицы по времени довольно затратно (0,2-0,3 с независимо от ее размера), а потому, например, в обработчике ПриПолученииДанных() или ПриВыводеСтроки() запросы с временными таблицами лучше не использовать.

(16) как говорил представитель 1С на выездном тренинге - разработчки 8.1 рекомендовали делать доступ к шапке через ТЧ. Разработчики 8.2. рекомендуют отдельно выбирать шапку, отдельно ТЧ и потом соединять. НО тут много зависит от версии базы (серверная или файловая. Если серверная, то от конкретной СУБД) + от тех данных, которые выбираются запросом!

В общем они сами не знают как лучше...уж больно субъективный момент - каждый запрос это частный случай. Поэтому я не сильно заморачиваюсь и если шапка нужна ток при наличии ТЧ - делаю через ТЧ с точкой

(18) а на сколько критично еще и уничтожение временной таблицы???

Ведь они накапливаются во временной базе скуля.
Если делать в конце запроса "Уничтожить ВТДокументы" - данные из темповской базы будут удаляться?

(0) я создавал ветку с похожим вопросом, можешь почитать:

v8: Вопрос по левому соединению

(20) А вот фиг знает. По логике, если не создаешь МенеджерВременныхТаблиц, то все временные таблицы должны автоматом уничтожаться после выполнения запроса (ведь дальше их использовать невозможно). А при наличии МенеджерВременныхТаблиц - при вызове деструктора этого самого менеджера. Только вот кто знает, когда он вызывается, и вызывается ли вообще.

(22) просто я стараюсь в запросах удалять временные таблицы. Т.е. создал таблицу, отработал ее и в самом конце запроса удаляю ее...вот думаю нужно это делать или нет.

(23) Ну, хуже-то не будет.

(21) Почитал.
Буду использовать третий вариант. Пусть будет как будет.

Еще вопрос.
Как лучше?

   ПриходнаяТТНТовары.Товар КАК Номенклатура

Или

   ПриходнаяТТНТовары.Товар.Ссылка КАК Номенклатура

по мне лучше явно:

ПриходнаяТТНТовары.Товар.Ссылка КАК Номенклатура

т.к. была у меня проблема при использовании "ВЫРАЗИТЬ". после этого если нужна ссылка всегда явно указываю!

(27) по крайней мере если писпользуешь в выборке
т.е.

Выбрать
ПриходнаяТТНТовары.Товар

Можно и так
А вот если делаешь соединения по этому полю, то наверное лучше все-таки

  ПриходнаяТТНТовары.Товар.Ссылка КАК Номенклатура

Спасибо

ПриходнаяТТНТовары.Товар.Ссылка
подтянет еще одну таблицу (номенклатуры, если не составной тип) - нафига?

(26) Если ПриходнаяТТНТовары.Товар простой тип, то лучше брать просто его.
Если составной, включая примитивные типы, то вместо ПриходнаяТТНТовары.Товар, имхо, лучше выразить как нужный тип

лучше всего конечно ПриходнаяТТНТовары.Товар.Ссылка.Ссылка.Ссылка для надёжности, да

при обращении к таблице тч
1с все равно делает джоин с таблицей документа. но в будущем могут и исправить.

+31 Всегда обращение через точку - join с таблицей. Особенно пикантно получается, если тип реквизита составной с ДокументСсылка

результат одинаковый, по этому выбирать надо тот запрос, которые читабельнее и понятнее. Конечно есть исключения - когда доказано, что нечитабельный вариант дает ощутимый прирост производительности

Ибо на первые два сервер создаст еще по 2 временные таблицы, на последнем - только 1