1С 8.1 Два одинаковых запроса, разный результат. Помогите разобраться. #517947

1С 8.1 15-я версия платформы, конфигурация УТ 10.3. Делаю запрос с участием свойств номенклатуры (на примере упростил). В первоначальном варианте 1С в результате запроса находила свойства товарам непонятным макаром. У каких-то товаров свойства в отчете появлялись, у каких-то нет (будем считать, что абсолютно у всех товаров нужное свойство заполнено). Может бы, я чего-то недопонимаю? Объясните, пожалуйста. Работающий вариант. А теперь неработающий вариант Отличия в запросах - в реализации левого соединения регистра со свойствами.

c точки зрения MS SQL, это абсолютно два разных запроса !!! Причем второй запрос может заставить серьезно напрячь сервак, если не будет индекса по полю ЗначенияСвойствОбъектов.Свойство. Во втором случае у тебя пропадает ЛЕВОЕ СОЕДИНЕНИЕ.

Эмм, с каких это пор левые соединения пропадают при использовании подзапросов? Часто ими пользуюсь, у 1С-ников тоже есть отчеты с такими вещами.

Давай без "упростил". Запусти конкретно эти 2 запроса и сравни результат. Будет отличаться - приходи еще. Будет одинаковый - думай.

они "пропадают", если ты условие накладываешь в секции ГДЕ итогового запроса ну т.е. в таком случае левое равносильно внутреннему

Повторяю. Я намучался с первоначальным запросом из сотен строк, начал искать неработающий кусок и в результате упростил до см. первое сообщение. Вот результат именно этих двух запросов и отличается, хотя теоретически должен быть одинаковым. Именно про эти конкретные два запроса из первого сообщения без никаких изменений я и спрашиваю. Так сойдет? Во втором запросе очепятка, последнюю строку "ПодзапросПродажиОстатки.Номенклатура = ПодзапросНужноеСвойство.Объект" заменить на Кстати, замерил сейчас производительность - второй запрос выполняется в пять раз быстрее первого, поле "значение свойства" не индексировано. Не знаю, как там с точки зрения скл серверов, но с точки зрения 1С я давным-давно вроде читал, что использование подзапросов может ускорить время выполнения запроса (только что вспомнил). А одинаковыми запросы я назвал с точки зрения результата запроса, безо всяких там технических тонкостей.

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

А что значит неработающий вариант? Вообще ни чего не выдает, или как?

У меня и тот и другой вариант отрабатывают одинаково. Результат одинаковый..

в чем фишка.. как заставить их выводить разные данные?

Работающий вариант запроса - отчет с этим запросом показывает правильные данные. Неработающий вариант - соответственно, отчет косячит. Гы, сегодня два часа мучился, тоже результат был одинаковый. Только мудрил на пытошной базе, которую получил таким вот макаром - сделал архивную копию (*.dt) рабочей базы, в пытошную загрузил эту архивную копию. В пытошной все замечательно, оба запроса работают как часы (как запросы в первом сообщении без изменений, так и с условиями по, допустим, номенклатуре и складу в поле ГДЕ или же с условиями в скобках у регистра остатков товаров). Думаю, совсем озверел Черный Абдула. Полез в рабочую базу, итого -в рабочей базе второй запрос косячит. Что-то с базой не то по ходу дела, буду делать тестирование, реиндексацию и чего там еще.

ПО ПодзапросПродажиОстатки.Номенклатура = ПодзапросНужноеСвойство.Объект

Смотрим внимательно имена таблиц в соединении

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

dimoff, это очепятка. Выше я уже поправил. Просто начал синонимы править в блокноте, чтобы народ не путать, да в одном месте не подправил.

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

нифига

а если во втором варианте еще и в ГДЕ добавить ЗначенияСвойствОбъектов.Объект ССЛЫКА Справочник.Номенклатура добавить - то будет еще быстрее. а вообще - при чем здесь индект на значениесвойства? + много. может база побилась?

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

Fragster, вот за доп. условие ГДЕ спасибо. "при чем здесь индект на значениесвойства?" - ой, точно, не то ляпнул, совсем озверел Черный Абдула со всеми этими свойствами! Короче да, база немножко сбрендила. Однако я так и не понял, почему тупит именно второй запрос. При слете индексов разве не первый должен был косячить? Ты же вот сам пишешь, что во втором запросе индексы не используются.

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

Значит, переиндексировать базу и все.

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

И ПодзапросНужноеСвойство.Свойство = &Свойство это как это???

А это есть секретная запатентованная мной фишка. Но лично тебе, камрад, разрешаю ей пользоваться бесплатно!

я почему то думал, что после слова По связи таблиц пишутся?

не, секретная фишка - это Таблица.Поле В (&Значение1, &Значение2)

а чем тебе это не связь таблиц?

ВЫБРАТЬ ИЗ

сделаешь ее в конструкторе запросов?

ВЫБРАТЬ ИЗ

легко

чойта?

Тогда между запросами разницы нет вообще никакой, либо чего-то не договариваешь, однако

спасибо, у меня без твоих секретных фишек запросы работают, в отличие от твоих)

ну он в запросе вродь хочет получить остатки номенклатуры с определенным свойством), эт запрос, который ему нид)

сделай и отпишись пожалуйста

На фйловой второй будет быстрее выполняться

На сиквеле должны быть одинаковы

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

ну, раз пожалуйста, то на:

нифига, я проверял - вариант с соединением у меня в любом режиме (кроме скульной на постгре) был не медленнее варианта с ГДЕ

сорри эт я от 7.7 уже начал тупеть

План смотрел?

скульную на постгре не проверял

я проверял на немного другом запросе :) там вариант с вложенным запросом попадал в тэйбл скан, а с соединением - в индекс скан

Объясни для дураков (для меня) чего это ты там понаписал. Запрос на самом деле посложнее будет, в конторе вовсю идут мутки с использованием свойств не по прямому назначению, меня не слушают! Бедный я нестчастный! Ты о чем про "нифига"? Не вижу никакой нифигы, ты же наоборот подтверждаешь слова того человека, которому отвечаешь. Мужики, так мне кто-нибудь ответит на вопрос? Черт с ней, со скоростью, лично мне на нее наплевать. Это все умник перевел обсуждение в другое русло.

Прочувствуйте разницу: 1) отобрать записи в регистре ЗначенияСвойствОбъектов по полям Объект и Свойство и соединить с таблицей товаров - левое соединение 2) выбрать все записи из регистра ЗначенияСвойствОбъектов, отобрав их по полю Свойство, затем, потеряв возможность соединения по индексу, соединить с таблицей товаров - каг бэ левое соединение с результатом вложенного запроса

Мужик, запросы абсолютно идентичны и работать сами по себе должны абсолютно одинаково.

+48 Разве что скорость первого будет быстрее

"Казалось бы, при чем тут" сбитые индексы?

у меня второй в ПЯТЬ раз БЫСТРЕЕ работает. Это уже на пытошной базу, исправленной так сказать.

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

Умник, я с самого начала хотел попросить тебя сначала прочитать всю тему, а уже только потом блистать интеллектом/отвечать. Разве это так сложно? Конечно же я сравнивал именно запросы из безо всяких изменений. Запросы абсолютно одинаковые, но тогда почему при слетевших индексах первый запрос продолжает работать нормально, а второй, якобы независящий от индексов, начинает косячить?

Извини, мужик, я не в курсе что такое "слетевшие индексы"

это твой ответ? в разжевал, теперь будем глотать: товаров в справочнике - 10000 позиций и по всем есть твое свойство, товаров на остатках - 2000 позиций в первом запросе соединяя таблицы, отбираешь в регистре не только по свойству, но и по объекту, причем делаешь это с использованием индекса - через индекс скан во втором запросе выбираешь ВСЕ 10000 записей из регистра свойств, теряешь индексы, соединяешь две таблицы и в момент соединения отбираешь по объекту, только уже через скан таблицы Вопрос - для чего придумали все эти индексы?

теперь понял что такое слетевшие индексы и понял

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

план запроса смотреть нужно было