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

ИЛИ

ВЫБРАТЬ
   ХарактеристикиНоменклатуры.Ссылка КАК Ссылка1,
   ВложенныйЗапрос.Ссылка
ИЗ
   (ВЫБРАТЬ
       Номенклатура.Ссылка КАК Ссылка
   ИЗ
       Справочник.Номенклатура КАК Номенклатура
   ГДЕ
       Номенклатура.Ссылка В(&МассивНоменклатуры)) КАК ВложенныйЗапрос
       ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ХарактеристикиНоменклатуры КАК ХарактеристикиНоменклатуры
       ПО ВложенныйЗапрос.Ссылка = ХарактеристикиНоменклатуры.Владелец

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

(0) Это разные запросы

(1) tempDB не резиновый!

ВЫБРАТЬ
   ХарактеристикиНоменклатуры.Владелец ,
   ХарактеристикиНоменклатуры.Ссылка КАК Ссылка1
ИЗ
   Справочник.ХарактеристикиНоменклатуры КАК ХарактеристикиНоменклатуры
ГДЕ
   ХарактеристикиНоменклатуры.Владелец В(&МассивНоменклатуры)

(2) +1

(4) не выведет номенклатуры без характеристик)

(2) ошибся )

(6) так и (0) не выведет

(2) имелось ввиду к справочнику номенклатура присоединяется спр. характеристики

вложенные запросы и их авторов на кол

(9) В первом запросе - фактически - ВнутреннеСоединение.

(3) так удалить же потом

(8) согласен, проглядел

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

+(14) вот 1ый вариант и 2ой в 0

не взял бы к себе на работу того кто вложенные юзает

(16) чем тебе не нравятся вложенные запросы?

(1) с чего вдруг быстрее? типа в (0) индексы юзаться не будут?

(17) А смысл их юзать где не попадя?

(12) Так не об этом речь.
Там толпа пользователей сидит, и все юзают эту бедную tempDB (сервер 1С любой чих через них собирает).
А тут ты с Индексами в полный рост.

(18) не будут

(16) И того кто РЛС использует?

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

(17) Подзапрос - это цикл в цикле фактически.

(24) Неправда

Для случая в (0) запросы равносильны (берем MSSQL)

(20) в данном случае не считаю это проблемой

(21) это с чего вдруг не будут то? у каждого справочника есть КЛАСТЕРНЫЙ индекс по полю ссылка.

интересно, и насколько индекс убыстрит соединение таблиц?

(25)
wiki:%C0%EB%E3%EE%F0%E8%F2%EC_%F1%EE%E5%E4%E8%ED%E5%ED%E8%FF_%E2%EB%EE%E6%E5%ED%ED%FB%EC%E8_%F6%E8%EA%EB%E0%EC%E8

(29) он может убыстрить только если индекса НЕТ

(29) мне тоже :) но что убыстрит - факт

(30) Не подзапрос, а соединение

(32) а вот мне что-то сомнительно

(30) подзапрос в ВЫБРАТЬ - да цикл в цикле. а когда идет соединение, там такого нет. изучаем планы

(28) речь про именно тот индекс который = условию связи, делать его для верменных таблиц при последющем соединении почти всегода даёт выхлоп!

(36) я про это же и говорю, по полю ссылка у справочника Номенклатура УЖЕ ЕСТЬ ИНДЕКС и он КЛАСТЕРНЫЙ. поэтому быстрее через временную таблицу не будет на 99.99999999999%

в данных случая, я могу применить временную таблицу, но если мне надо в этой временной таблице получать по отбору строки?
Именно для этого я и спрашиваю, что будет быстрее, соединять с отобранными данными, или соединять а потом отбирать?

(38) сначала отбираешь,  уменьшая размер соединяемой таблицы, потом соединяешь.

(39) так и думал, но надо же было вынести на мисту для уточнения ))

(37)подзапрос или левое?

(41) для скуля монопенисуально

(38) в данном случае монопенисуально, если речь про скуль сервер

(11) почему?

(39) Как ты определишь что в первом запросе соединение раньше отбора? Потому что выше написано?

(43) не согласен, но аргументов привести не могу :)

(45) я отвечаю на вопрос в (38)

(43)не-а, план выполнения - дело тонкое...

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

(45) странный вопрос... может ты тогда сейчас будешь утверждать, что преобразуются они и будут идентичны?

Второй запрос (который с подзапросом) привел к Nested Loops. ЧЯДНТ?

(50) План вполне может быть одинаков. Да скорее всего так и будет

(51) А первый?

(51) и подсказки оптимизатору из одынэсе не сделать...

(53) А первый тоже.

(51) планы в студию

А похоже все хорошо

SQL соединение отображает как Nested Loops

(55)опа! Временные рулят!!! Что собственно и требовалось доказать

(56) +1

(59) опа у тебя в голове. оба плана одинаковые
(58) nested loops - метод соединения таблиц. и он может быть 3х видов.

(0)а померять не пробовал? )))
второй конечно, но чтобы замер подтвердил нужны очень большие таблицы

(61)безосновательно, мою парвоту доказывает что вы переходите на личности!

(62) пробовал, нет такого количества данных, чтобы реально замерить.

(62) сам то пробовал?

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

Для первого запроса - Index Scan по Номенклатуре и Index Seek по характеристике.
Для второго запроса - Clustered Index Seek по Номенклатуре и Index scan по Характеристике.

(63) зато теперь я знаю какой вопрос можно задавать на собеседование. и отсеивать "знатоков" которые подтверждают свою правоту по косвенным признакам, которые никаким боком на фактах не основаны

(64)а зачем тему поднял?

(66) в пакетном запросе можно - будет тоже 1 запрос

(67) в массив много вбухал то значений?

(71) 3 номенклатуры.

(72) а если первый запрос на внутреннее переделать? и правое, то какие планы?

(67) Странно, ты точно корректный 1 запрос взял, а не тот что в (0)?

(74) Тот что в (0)

(75) бери тот, что в (14)

О, ёштель-моштель, все в кучу, и кони, и яйца, и nested loops сюда же.

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

так замеры уже былил, или нет?

(77) а на файловой - фиг

(79) на файловой вообще *опа.

Для запроса (14) - Clustered Index Seek по Номенклатуре и Index seek по Характеристике.

кстати, нужно ещё учитывать многообразие поддерживаемых SQL-СУБД

Ладно, скучно.
Пойду борща поем.

(81) Т.е. планы абсолютно одинаковы, что в принципе и видно сразу было

(83) Прям как бабка из камеди клаб:
Поем борща, послплю,
Посплю, поем борща

(84) планы получается разные. в первом случае (правильно) из (14) сик + сик
во втором случае с вложенным запросом из (0) сик + скан

(86) за мс-сиквел не убедили за постгресс и ДБ2 говорить бум?

(67)замеров из ТЖ не осталось? Вот-бы их сравнить с пакетным запросом

(88) а что в пакете то?

(89) то что пытались сунуть в подзапрос: Справочник.Номенклатура

(90) куда быстрее то? seek+seek - самый быстрый, быстрее уже никакк.
сик+скан - чуть медленее. Между ними никаких вариантов не может быть. А временными кудаткут лезть?

(91)>seek+seek
эээ, действительно, индексированный поиск уже быстрей некуда