Опять три варианта!
Кто круче ЛефтДжоин, ЮнионОлл, или Временная таблица?!
(есссно, Контрагент в Таблица1 и Таблица2 встречается только по одному разу)

1. Левое соединение к подзапросу - здесь в условии подзапроса может быть любое другое условие, не обязательно отбор по Контрагентам

ВЫБРАТЬ 
   Таблица1.Контрагент как Контрагент,
   Таблица1.Поле как Таб1Поле,
   Подзапрос.Поле как Таб2Поле
Из Таблица1 как Таблица1
    ЛевоеСоединение (Выбрать 
							Таблица2.Контрагент, 
							Таблица2.Поле 
						ИЗ Таблица2 как Таблица2 
						ГДЕ 
						   Таблица2.Контрагент в (&СписокКонтрагентов)) как Подзапрос
    ПО Таблица1.Контрагент = Подзапрос.Контрагент
ГДЕ Таблица1.Поле2  в (&СписокКонтрагентов)

2. Юнион с группировкой - наверное самый оптимальный вариант

ВЫБРАТЬ
              Подзапрос.Контрагент как Контрагент, 
	МАКСИМУМ(Подзапрос.Таб1Поле) как Таб1Поле,
	МАКСИМУМ(Подзапрос.Таб2Поле) как Таб2Поле
ИЗ 
(
	ВЫБРАТЬ
                             Таблица1.Контрагент как Контрагент,
		Таблица1.Поле как Таб1Поле,
		NULL как Таб2Поле
	ИЗ
	    Таблица1 как Таблица1
	ГДЕ Таблица1.Контрагент в (&СписокКонтрагентов)

	ОБЪЕДИНИТЬ ВСЕ

	ВЫБРАТЬ
                            Таблица2.Контрагент,
		NULL,
		Таблица2.Поле3
	ИЗ
	    Таблица2 как Таблица2
	ГДЕ Таблица2.Контрагент в (&СписокКонтрагентов)

) как Подзапрос
ГРУППИРОВАТЬ ПО Подзапрос.Контрагент

3. Временная таблица и левое соединение - самый читабельный

Выбрать 
	Таблица2.Контрагент, 
	Таблица2.Поле 
ПОМЕСТИТЬ ВремТаблица2
ИЗ Таблица2 как Таблица2 
где 
   Таблица2.Контрагент в (&СписокКонтрагентов)
;

ВЫБРАТЬ 
   Таблица1.Контрагент как Контрагент,
   Таблица1.Поле как Таб1Поле,
   ВремТаблица2.Поле как Таб2Поле
Из Таблица1 как Таблица1
    ЛевоеСоединение ВремТаблица2 как ВремТаблица2
    ПО Таблица1.Контрагент = ВремТаблица2.Контрагент
ГДЕ Таблица1.Поле2  в (&СписокКонтрагентов)

З.Ы.: Писал без конструктора, если что простите за синтаксические ошибки

Блеать, по коду нужно отгадать решаемую задачу?

(1) учись, студент! ©

(3) да нет никакой задачи!

Я накидал три примера. Предлагаю обсудить достоинства и недостатки каждого метода.

З.Ы.: Гуру от запросов всяческим калом поливают левое соединение, дескать та таблица что справа (Таблица2) будет перебираться столько раз сколько строк в левой таблице (Таблица1) и я обычно где можно пытаюсь заменить левое соединение юнионом.

(5) и всё-таки, что должен получить запрос?

(7) р-р-р!!! Да ничего он не должен получить! Абстрактный пример!

Видишь первый запрос?
Подзапрос в нём будет работать один раз, или столько раз сколько строк в Таблица1 ?
Или столько раз сколько строк в Таблица1, удовлетворяющих условию в "ГДЕ" ?

(8) сначала отработает подзапрос, потом будет сделано соединение с результатом

(9) я тоже так предполагал.

а обосновать как то можешь?

(11) ну, могу лишь предложить заглянуть в ТЖ, чтобы увидеть скуль-запрос, в который транслируется данный текст

(15) потому что левое соединение аццкое зло! См. (5)

Гуру от запросов всяческим калом поливают левое соединение, дескать та таблица что справа (Таблица2) будет перебираться столько раз сколько строк в левой таблице (Таблица1) и я обычно где можно пытаюсь заменить левое соединение юнионом.

в 1 и 3 запросах имеем две входных таблицы размером N, N x N сопоставлений строк, и на выходе результат размером N

во 2 запросе имеем имеем две входных таблицы размером N, промежуточную таблицу с числом строк M = 2N, по которой осуществляется группировка с вычислением агрегатных функций, и на выходе результат размером N.

при группировке и агрегировании нужно, как минимум, произвести сортировку промежуточной таблицы, при этом в зависимости от алгоритма сложность будет от O(M x M) до O(M log M)
я не гуру запросов, и что-то мне пока не очевидно преимущество. конечно, много ещё зависит от конкретных планов запросов, которые будут построены СУБД.
но как минимум хотелось бы видеть некие результаты тестирования на реальных данных больших размеров

(17) делал подсчет количества строк в документах за месяц (порядок сотня тысяч доков). Через левое соединение, а там похоже тупой перебор строк таблицы подзапроса по каждой строке соединяемой, это дико долго, кароче имхается, что на больших и огромных выборках, временная таблица с ИНДЕКСИРОВАТЬ ПО - рулит, а левое соединение - жуткий сакс и отстой (нечто очень плохое).

(18) понятно, что индекс добавить драйва, но вопрос-то не в этом, т.к. индекс добавит драйва обоим вариантам.

а есть под рукой тексты запросов, про которые ты упоминаешь?

3-ий вариант самый православный и единственный который разумно отработает на ВСЕХ СУБД, а вот первый и второй вариант "НА НЕКОТОРЫХ СУБД(не будем показывать пальцем)" могут не родится.

p.s. Свой вывод пишу по платформе 8.2 релиза 11 года в связке ЗУП на Oracle, эта СУБД убивает(ла) любые вложенные запросы сцуко. Приходилось очень многое переделывать на ВТ.

(18) во! Почти слово в слово (16)

(20) именно так, вот слова представителей 1С "Типичные причины неоптимальной работы запросов и методы оптимизации"
Рекомендации

При написании запросов не следует использовать соединения с подзапросами. Следует соединять друг с другом только объекты метаданных или временные таблицы. Если запрос использует соединения с подзапросами, то его следует переписать с использованием временных таблиц.

Если запрос содержит соединения с подзапросами, то это может привести к следующим негативным последствиям:
Крайне медленное выполнение запроса при слабой загрузке серверного оборудования. Замедление запроса может быть очень значительным (до нескольких порядков).
Нестабильная работа запроса. При некоторых условиях запрос может работать достаточно быстро, при других - очень медленно.
Значительная разница по времени выполнения запроса на разных СУБД.
Повышенная чувствительность запроса к актуальности и полноте статистик. Сразу после полного обновления статистик запрос может работать быстро, но через некоторое время опять замедлиться.
Пример потенциально опасного запроса, использующего соединение с подзапросом:

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

В данном примере в правой части соединения используется подзапрос, а не объект метаданных. Обратите внимание на то, что в какой части соединения (правой или левой) используется подзапрос - не важно. Точно так же не важно, какого типа соединение указано (ЛЕВОЕ, ПРАВОЕ и т.д.). Во всех случаях такая конструкция является потенциально опасной и должна быть исправлена при помощи временных таблиц.

Обратите внимание на то, что возможность использования временных таблиц появилась в 1С:Предприятии начиная с версии 8.1. Если вы используете версию 8.0, то для решения проблемы производительности такого запроса следует перейти на 8.1.

Для оптимизации запроса следует разбить его на несколько отдельных запросов (по числу подзапросов, используемых в соединениях). Эти запросы рекомендуется поместить в один пакетный запрос.

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

Только ВТ, будьте умничками

(23) а паааачиму только ВТ?
Я, например, за Юнион!

(24) Да пусчай будет юнион, но только не вложенным делай, а через ВТшку. И буит счастье на любой СУБДшке !

(24) Юнион хуже ВТ хотя бы потому, что код запроса получается длинным.

Насчет UNION есть еще другая, интересная рекомендация

Использование логического ИЛИ в секции ГДЕ запроса

Не следует использовать ИЛИ в секции ГДЕ запроса. Это может привести к тому, что СУБД не сможет использовать индексы таблиц и будет выполнять сканирование, что увеличит время работы запроса и вероянтность возникновения блокировок. Вместо этого следует разбить один запрос на несколько и объединить результаты.
Например, запрос

ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "001" ИЛИ Артикул = "002"

следует заменить на запрос

ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "001"
|ОБЪЕДИНИТЬ ВСЕ
|ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "002"

(28) ну и как? Пользуешься агрегатами?

(29) Нет. Еще не разу не довелось.

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

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

поподробнее, плс
там конечно в условии "ГДЕ Таблица1.Поле2 в (&СписокКонтрагентов)" косяк, по идее надо было бы "ГДЕ Таблица1.Контрагент в (&СписокКонтрагентов)", но почему ты считаешь что в результат первого запроса попадут Контрагенты из второй таблицы, кторых нет в Таблица1?

(32) Пардон, в 1 пункте-то левое, чет спросоня показалось что там в условии "ПО" проверка на вхождение в список, а не по Контрагенту связь. Ну да второй вариант все-таки полное. Выбираются все контрагенты которые есть в списке со всеми числами, тогда как в 1 и 3 только те, которые есть в таблице1. Уже поэтому их сравнивать некорректно по производительности. Если подразумевалось все же полное, а не левое, то вариант 2 быстрее прочих, так как полное это сначала левое, потом правое, потом группировка = дольше.

Дядя Васька отчего третий вариант вообще теряет смыс

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

(36) Так тут и с теорией-то не выходит, слишком простые запросы. Да еще и теплое с мягким сравнивается. Левое в 1 и 3, с полным в 2. Можно например вот такое сравнить со вторым вариантом:

ВЫБРАТЬ 
   Таблица1.Контрагент как Контрагент,
   Таблица2..Поле как Таб1Поле,
   Подзапрос.Поле как Таб2Поле
Из Таблица1 как Таблица1
    ЛевоеСоединение Таблица2 как Таблица2
    ПО Таблица2.Контрагент  в (&СписокКонтрагентов)
ГДЕ Таблица1.Контрагент  в (&СписокКонтрагентов)

Тут вроде как сопоставимо. А временные таблицы вообще не лезут, слишком простой пример. С ними в любом случае лишнее телодвижение будет.

(9) ты не прав...

(39)обоснуй
(40)+1 тоже так подумал, но не стал спорить с автором. Будто в скуле не те же самые соединения.
(41) Фирма 1С против соединений с подзапросом, см. (22)

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

(43) соединения не создают временные таблицы. Конструкция "поместить в ВТ_Контрагенты" переводится примерно как "Create table #t11" при этом на стороне sql, таблица #t11 физически создается в tempdb. При выполнении соединений, tempdb не используется. Соединения могут выполнятся 3 мя алгоритмами
1. Хэш соединение http://www.sql.ru/articles/mssql/2007/051103hashjoin.shtml
2. Соединение вложенных циклов http://www.sql.ru/articles/mssql/2007/051101nestedloopsjoin.shtml
3. с сортировкой слиянием http://www.sql.ru/articles/mssql/2007/051102mergejoin.shtml
Оптимизатор сам выбирает какой алгоритм применить, какой алгоритм применен видно из плана выполнения запроса.

(42)

1. Порядок выборки данных будет определен при составлении плана запроса на основании ряда параметров системы (индексы, статистика, системные ресурсы и т.д. и т.п.). Если скуль решит, что выгоднее подзапрос сунуть позже, то сунет.
3. Фирма 1С не против, просто соединение с подзапросом может в некоторых случаях работать непредсказуемо. Что бы добиться предсказуемости и рекомендуют временные таблицы создавать, хотя они могут по времени выполнения серьезно проигрывать.

(46) ИМХО перегибаешь. Нельзя утверждать, что временные таблицы всегда размещаются на диске, а выборки подзапросов в оперативке. Скуль сам управляет памятью, стараясь максимально эффективно задействовать оперативку, кэширует. Временные таблицы и выборки подзапросов кушают память одинаково. Сумеет ли скуль запихнуть данные в физическую память или будет свопить зависит от их размера и доступности ресурсов.

(46) Не важно сколько железа на серваках и какого оно качества, адресация временных таблиц сервером 1С конечна.

(48) Временными таблицы создаются на скуле. Причем здесь сервер 1С? По логике ему безразлично как скуль сварил выборку, с ВТ или без, он получает готовый набор данных.

(49) Сервер 1С их адресует и на адресацию есть предел.

Морозов вроде упоминал 30-40 единовременных ВТ

(50) Такую инфу надо проверять. В реале на такие грабли, даже если это правда, наступить непросто. Надо быть большим фанатом ВТ, чтобы наплодить их столько в одном пакете.

Проверить не сложно.

NcSteel А скуль запрос тут при чем?

Как скулевский запрос влияет7

ну, в итоге-то будет выполняться скулевский запрос (или мы принимаем во внимание файловые базы?)

(53) Будет выполняться план запроса. План запроса будет строится на основании многих параметров и текст запроса является одним из этих параметров.

(54) это понятно. просто ты так интересно выразился, будто пляска идёт от текста запроса на языке 1С. а ведь он лишь транслируется в текст скулевского запроса (и не факт, что он даже внешне будет похож на 1с-вский)

(55) ну уж так и не до узноваемости!
Понятно что там всякие виртуальные таблицы в подзапросы переделаются, неявные соединения через точку в явные и т.п., но главная то тема, про которую мы говорим - лефт джоин vs юнион vs Времененные таблицы так и останется актуальной для SQL.