Помогите составить оптимальный по времени выполнения запрос для выборки доков (РеализацияТоваровУслуг) с пустой табличной частью Товары. База на мсскл2008

Количество=0

имеющие

ИМЕЮЩИЕ
   СУММА(Документ.ТЧ.Поле) = 0

Левое соединение шапки с табличной частью по условию
ГДЕ
ТабличнаяЧасть.Ссылка ЕСТЬ NULL

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

ВЫБРАТЬ
   РеализацияТоваровУслугТовары.Ссылка
ИЗ
Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслуг
Сгруппировать По РеализацияТоваровУслугТовары.Ссылка
Имеющие Количество(*) = 0
не?

Последний вариант - первое, что мне пришло в голову, но он, к сожалению, весьма медленный. Цель найти оптимальный вариант.

Сори, имел в виду пост (5)

попробуй
выбрать
шапка.ссылка где шапка.ссылка не в (выбрать табчасть.ссылка)

(8) Оптимальнее чем в (5)?????

может быть выбрать документы с непустой табличной частью и потом использовать НЕ В?

(10) думаю, есть оптимальней

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

(13) ... готовые варианты = нормально? Вот бы мне так жить.

Голова тогда зачем?

(12) Ошибаешься. Голову включи. Соединение надо? Надо. А больше там и нет ничего.

Голова на месте. Хотелось бы, чтобы советчики сперва сами попробовали свой способ :)

(16) Так пользуйся, если на месте!

(12) если я приведу способ быстрее, чем (5) - ты усомнишься кому из нам стоит включить голову? :)
Дело не в мерянье письками, я реально пытаюсь найти быстрейший способ

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

(19)На уровне обычной логики - да, правильно. Но...
Повторю вопрос (18)

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

(20) Формализация задачи на языке запросов SQL в (5) выполнена буквально теми же словами. Удачи в поиске "быстрых" вариантов.

(21) У автора это медленно работает. Он считает, что запрос неоптимален. Одно единственное соединение, без которого в любом случае не обойтись - для него неоптимальное решение.

(18) Ну давай же приводи побыстрее, не томи......

(23) Сравни мой вариант с (5) и найди отличие :))

(21) Твой запрос НЕ верен. 2е условие соединение никогда не отработает

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

(25) Таки да. Не заметил. В самом деле, твой вариант нерабочий.

(26) А, ну да, ошибся, нельзя так :))

(27) в условии нужно еще добавить РАЗЛИЧНЫЕ

Хе-хе, печально я гляжу на наше поколенье...
И это люди в большинстве своем имеющие серты спецов по платформе :)

(31) не томи уже. Давай свой супер пупер вариант.

(32)Зачем? Подождем когда подтянутся гуру. Или они уже все отметились? :))
Тем паче что я пока сам в поисках окончательного варианта.
Хотя и нынешний процентов на 30-40% быстрее (5)

Тогда я бы предложил либо

ВЫБРАТЬ РАЗЛИЧНЫЕ
   РеализацияТоваровУслугТовары.Ссылка
ПОМЕСТИТЬ ДокументыСТабличнойЧастью
ИЗ
   Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
ГДЕ
   РеализацияТоваровУслугТовары.НомерСтроки = 1
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
   РеализацияТоваровУслуг.Ссылка
ИЗ
   Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
ГДЕ
   (НЕ РеализацияТоваровУслуг.Ссылка В
               (ВЫБРАТЬ
                   ДокументыСТабличнойЧастью.Ссылка
               ИЗ
                   ДокументыСТабличнойЧастью КАК ДокументыСТабличнойЧастью))

либо

ВЫБРАТЬ РАЗЛИЧНЫЕ
   ВложенныйЗапрос.Ссылка,
   СУММА(ВложенныйЗапрос.НомерСтроки) КАК НомерСтроки
ИЗ
   (ВЫБРАТЬ РАЗЛИЧНЫЕ
       РеализацияТоваровУслугТовары.Ссылка КАК Ссылка,
       1 КАК НомерСтроки
   ИЗ
       Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
   ГДЕ
       РеализацияТоваровУслугТовары.НомерСтроки = 1
   
   ОБЪЕДИНИТЬ ВСЕ
   
   ВЫБРАТЬ
       РеализацияТоваровУслуг.Ссылка,
       0
   ИЗ
       Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг) КАК ВложенныйЗапрос

СГРУППИРОВАТЬ ПО
   ВложенныйЗапрос.Ссылка

ИМЕЮЩИЕ
   СУММА(ВложенныйЗапрос.НомерСтроки) = 0

PS: Скорость не проверял ессно, то есть не утверждаю, что будет быстрее :))

(33) Файловая небось? Если клиент-сервер, то чей сервер БД?

(35) А внимательно прочесть первый пост затруднительно?

(34)Складывается ощущение, что 1с-девелоперы совершенно не утруждают себя пониманием простейших вещей. 1)2 выборки, там где можно обойтись одной - это ОЧЕНЬ плохо. 2)Агрегатные функции это точно такое же зло в плане быстродействия.
Впрочем, все понятно. "Тормозит база? Докупите еще пару сервов в кластер. Это не софт кривой, это у вас железо не тянет". Правда? :)))

(37) Не надо грязи.
Прочитай PS.

(37) Запрос:
ВЫБРАТЬ
   РеализацияТоваровУслугТовары.Ссылка
ИЗ
   Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары

НЕ выберет ссылки в которых табличная часть пустая. Соответственно одну выборку к какой таблице будем строить?

Могу страждущим подкинуть вариант для размышлений, скорость на уровне (5) Это дабы особо умные поняли, что соединения здесь не нужны.
ВЫБРАТЬ
Реализация.Ссылка КАК Ссылка
ИЗ
Документ.РеализацияТоваровУслуг КАК Реализация
ГДЕ
НЕ Реализация.Товары.Ссылка=Реализация.Ссылка;

(40) Это выборка из одной таблицы? LOL

Мда...Комментарии излишни. Может все-таки, прежде чем строить домыслы, проверишь КАК это работает?

(42) Реализация и Реализация.Товары хранятся физически в одной таблице или нескольких? :))

Разумеется в разных. А ты не чувствуешь разницы между ПОЛНОЙ выборкой из Реализация.Товары и конкретной проверкой
Реализация.Товары.Ссылка=Реализация.Ссылка ? :)

(44) А ты не понимаешь, что насколько я понимаю у тебя получается коррелирующий запрос? :))
Тебя не смущает время на уровне (5)? Казалось бы, почему? :))

exec sp_executesql N'SELECT
_Document388_Q_000_T_001._IDRRef AS f_1
FROM
_Document388 _Document388_Q_000_T_001 WITH(NOLOCK)
WHERE
NOT EXISTS(SELECT 1 FROM _Document388_VT10200 WITH(NOLOCK) WHERE _Document388_Q_000_T_001._IDRRef = _Document388_VT10200._Document388_IDRRef AND
_Document388_Q_000_T_001._IDRRef = _Document388_VT10200._Document388_IDRRef) AND _Document388_Q_000_T_001._Date_Time < P1',N'P1 datetime','4011-06-01 00:00:00'

(44) Ну и где тут запрос к одной таблице? Два селекта к двум таблицам...

(46) Разве я утверждал, что на уровне скуля не будет 2 селекта? ;)
Ты сравни теперь этот скуль-запрос с левым соединением.
А потом с
"ВЫБРАТЬ
   |    Реализация.Ссылка КАК Ссылка
   |ИЗ
   |    Документ.РеализацияТоваровУслуг КАК Реализация
   |ГДЕ
   |НЕ Реализация.Товары.НомерСтроки В (&Массив)";

   
   Массив = Новый Массив();
   Массив.Добавить(1);
   Запрос.УстановитьПараметр("Массив", Массив);
Этот вариант в 1,5 раза быстрей ,чем (5)

Кстати, вполне можно обойтись без массива, достаточно
НЕ Реализация.Товары.НомерСтроки В (1)
однако выигрыша я не увидел

А если так

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

  РеализацияТоваровУслугТовары.Ссылка ЕСТЬ NULL


(49) Попадаем на индекс по номеру строки и нет лишних соединений

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

а (47)?

(52) мне лень, я уж впн разъединил. В боевых условиях это все все равно нафиг не нужно, т.к. кроме скорости важна еще и поддержка, которая такими (40),(47) трюками будет затруднена. 2мс не стоят того, чтобы в будущем морщить лоб, пытаясь понять: "что что же это я в том году имел в виду сказать таким е..нистическим запросом?.."

(53) Ога. Я так и вижу себя стоящим перед заказчиком и на вопрос гендира "какого х все юзера орут про тормоза?" отвечаю "йопта, не хочу в будущем морщить лоб... Сделал как проще" :))

(54) Не ерничай.
Докажешь, что твой запрос оптимальнее, приходи топорщить грудь.
Пока что-то не видно преимущества.

PS: Желательно с текстом запроса из профайлера.

(54) ну, что ты несешь, окстись. Где тормоза и где 2 миллисекунды?

Во-первых, "преждевременная оптимизация корень всех зол" (с) д. Кнут

Во-вторых, это перфекционанизм, который тоже до добра не доведет

(49)респект, всего лишь процентов на 5 проигрывает (47)

(56) Оп, уже и кнута помянули:) А что ж он 3 тома расписывал про быстрые алгосы, как думаешь? Или ты считаешь, что он свои нехитрым трудом хотел выразить сладкую мысль всех отчественных девелоперов:"главное сдать в срок,а там ниипет"?

(47) Да. Этот вариант быстрее. Не в 1,5 раза, но быстрее. Остроумное решение.
Но увеличение скорости здесь не за счет отсутствия соединения (оно никуда не девается, либо оно, либо коррелирующий подзапрос к другой таблице - в любом случае план выполнения сопоставляет данные двух таблиц), а за счет остроумного отбора строк второй таблицы.
Так что ты был прав. Но тешить самолюбие на протяжении полста постов - выглядит несколько по-детски.