Тормозит запрос по регистру "ДополнительныеСведения" в БП 3.0 #707117

Доброго всем дня Делаю обработку которая преобразует возвраты в документы поступления. Исходные номер и дату возврата решил записывать в дополнительные сведения документа поступления чтобы потом искать по ним. Сведения определяются в ПВХ как : Объект.СвойствоНомерВозврата   = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоНаименованию("Номер документа возврата (Поступление товаров и услуг)",ИСТИНА); Объект.СвойствоДатаВозврата    = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоНаименованию("Дата документа возврата (Поступление товаров и услуг)",ИСТИНА) для поиска документа поступления использую такой запрос : "ВЫБРАТЬ     НомераВозвратов.Ссылка ИЗ (ВЫБРАТЬ         ДополнительныеСведения.Объект.Ссылка КАК Ссылка ИЗ РегистрСведений.ДополнительныеСведения КАК ДополнительныеСведения ГДЕ ИЗ РегистрСведений.ДополнительныеСведения КАК ДополнительныеСведения ГДЕ Запрос работает но тормозит ужасно : время выполнения up 10 секунд. ЧЯДНТ ?

ДополнительныеСведения.Объект.Ссылка КАК Ссылка заменить на ДополнительныеСведения.Объект КАК Ссылка

Не делайте соединения с выборкой. Никогда. Соединяйте или с таблицей, или с временной таблицей.

Помогло спасибо

с чего бы это?

С того бы это. Но автору хватит и

sql может выбрать очень неоптимальный алгоритм соединения в этом случае..

+ еще использовать Выразить для составных типов

кароч переписывай)

но основные тормоза имхо из-за

тото я смотрю последние веяния писания запросов - пихать одну-две записи в ВТ, а потом ее юзать в соединении херня полная, надо смотреть планы, а уж потом юзать ВТ

время на создание вт некритично, соединять всегда лучше с вт, чем с выборкой

почему это не распространено в т-скл или рл-скл? вот что меня мучает

да-да, продолжай.

какие ваши доказательства?

Рупасов, для тебя не авторитет?

кто это?

=)

ты так это написал, что я должен был сразу пасть ниц? )))

посмотрел статью на ИТС - есть исключения из правила так что - следовать слепо рекомендациям тоже плохо

ну просвещайся =)

Еще как распространено. Скажу больше, там (MS SQL!!!) можно декларировать таблицы в памяти - годная, дико годная вещь для 1С-ки с учетом того, что 1С часто меняет временные таблицы (создает, удаляет) и я немного не понимаю, почему 1С не добавит это в платформу. Мыслей 2: 1) Хранить в памяти SQL большие объемы - не комильфо, но где 1С-ники их возьмут :-) да и можно отдать это на откуп программерам. 2) Для таблиц в памяти нельзя создавать индексы, но и это можно отдать на совесть программерам.

3) Всякие левые богомерские sql-и (постгрии, ibm db) могут не поддерживать эту штуку и 1С толерастно не запиливает ее только для рассово верной ms sql. Это скорее всего главная причина.

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

ты меня иногда поражаешь своей верой )))

+ 100

Запросы, выполняющие соединение с вложенными запросами или виртуальными таблицами - такую нашел в стандартах и методиках

не только  т-скл-ом живо человечество!!!

Тоесть?

всякая тварь, то бишь субд, достойна жизни!

ПРИМЕР ИСКЛЮЧЕНИЯ?

Это по мнению 1С. Я его не поддерживаю.

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

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

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

Слушай разговор ни о чем. Когда есть тормоза при выполнении запроса и выполнены все рекомендации из , конечно следует анализировать план и ВОЗМОЖНО переписать на вложенный запрос. Но согласись что ситуации, когда нужно ВТ переписать на вложенный встречаются на очень много реже, чем наоборот, поэтому изначально следует писать, используя ВТ

разговор всегда о чем, если есть суть разговора... )

у меня нет цели убедить тебя, для себя я сделал вывод, как писать)

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

А можно ссылку?