Видите ли вы преимущества пакетного запроса перед использованием нескольких запросов? Какие?

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

Допускаю, что при слабой связи, например в мобильном приложении или в веб-клиенте, есть смысл сократить количества обращений к серверу и делать пакетами. А в прочих случаях?

(15)
Процедура БезЦикла(КоличествоИтераций, Н = Неопределено)
    Если Н = Неопределено Тогда
        Н = 0;
    КонецЕсли;
    Н = Н + 1;
    Если Н<=КоличествоИтераций Тогда
        Сообщить(Н);
        БезЦикла(КоличествоИтераций, Н);
    КонецЕсли;
КонецПроцедуры

БезЦикла(15);

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

Сейчас, на УФ, имеет смысл только для удобства, всё и так на сервере делается, а СУБД будет вызвана в любом случае несколько раз.

(25) нет же, автоматическая сборка мусора, это прекрасно
в шарпе и яве тоже есть пустой указатель null, но не стоит его путать с NULL из SQL

(28) Если один запрос, и данные берутся только из него, то обращение к БД будет только одно. Не?

(27) вариант с перейти ближе к циклу. Не используется стек (стэк).

пакетный запрос это синтаксический сахар:
1. удобно редакктировать как единый запрос в конструкторе
2. тоже самое в СКд
3. не надо напрягаться с удалением временных таблиц

(27) При относительно небольшом кол-ве итераций (сейчас не вспомню точное число, но что-то емнип около 40000) - 1С упадёт, не успев даже ругнуться :)

(31) в определенных кругах за "перейти" пальцы прищемляют дверью

(33) надо будет затестить

(30) Нет.
Более того, обращений к СУБД может быть несколько даже при 1 запросе (когда используются ВТ (особенно регистра бухгалтерии) или конструкции "В иерархии", ну и еще наверняка есть варианты)

(34) а за рекурсию вместо цикла нет? НюНю...

Менеджер временных таблиц лучше пакетника, если к одной временной таблице обращаешься несколько раз. У меня таких задач не помню, чтобы было. А зачем еще?

(36) еще всякие срезы последних. 1 запрос 1С >= 1 запрос к БД :)

(36) хотя, да. Помнится, пытался трасернуть штатную ОСВ, которая на СКД. И глаза разбежались...

(21) в языке Фортран-4, которому меня учили на первом курсе, циклы примерно так и выглядели, через if и goto

ну, вы ещё язык Ассемблера вспомните или маш.код

нафига городить с созданием менеджера ВТ, когда можно выполнить пакетный?

(35) Я наврал. ОФ на 2.3.8 упала на 2025-й итерации :)))

(43)->(0)

В Ассемблере даже не цикл, а просто условие через "goto" всё равно ;)

(46) было в (2)

(47) Там речь про циклы!

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

(43) из-за оптимальности: выбрали доки в ВТ, потом на её основании добираем нужную информацию

(44) тоже затестил. Упал на 2026 :)

1С:Предприятие 8.3 (8.3.8.2027)

(38) если у тебя пакетный запрос, то юзать МВТ вообще без нужды

(49) Какое это имеет отношение к "Менеджер ВТ или пакетный запрос"?
И там и там много планов.

(49) так это ты реготчетность с закрытием месяца пишешь? держи его, пасаны!

А еще временные таблицы можно индексировать...

а в пакетном нельзя?

(54) Индекс, кстати, всегда 1 и кластерный.

(52) Про оптимизатор почему-то забыли.
(53) к счастью нет.

(52) В пакетном запросе, теоретически, можно выполнять несколько запросов на СУБД одновременно, если они не используют данные друг друга.

(57) План составляется на каждый конкретный запрос. Всегда. Пакеты, не пакеты - пофигу. Или не составляется, если запрос вызывается через ХП и есть кэш.

(58) это если MS SQL и включен параллелизм? Тоже надо тестить... А реально было бы интересно. Если создаешь двумя запросами две разные ВТ, а потом с ними работаешь - было бы круто, если бы они формировались одновременно.

(60) Параллелизм работает внутри 1 запроса.
Запросы в пакете выполняются последовательно.

(61) Это да. Согласен. Меня там больше на фантазии понесло.

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

(61) Выполняются последовательно 1С или MS SQL?

все такие умные. а где хранятся временные таблицы?
если явно объявлен менеджерВТ, то на стороне предприятия. и вся эта когорта передается из\в СУБД для дальнейших запросов. логично? пока да.
а вот пакетный запрос. 1с готовит запросы и отдает их в СУБД для исполнения, при этом где времянки? в ТемпДБ СУБД? или они перекатываются в сервер 1с для обработки в 1с?
судя по монитору ресурсов - rphost при запросе немножко тужится и высырает что-то в скуль. дальше скуль тужится и один раз отдает все скопом в рпхост. но запрос тем временем большой и пакетный... простите за сумбур.

(65)
Временные таблицы хранятся на СУБД и никуда не передаются.
Так что логика не очень.

(66) а как это я ВТ могу помацать из отладчика если она на субд?

(65) ВТ все в tempdb...

(67) Отладчик запрос к субд на содержание ВТ делает. Точно также, как и наименование справочника ты можешь посмотреть из отладчика. Прикинь, он не хранит это в сервере ;)

(67) ты выборку с нее "мацаешь".

(69) наименование справочника это ж метаданные, они всегда на сервере есть.

(67) И как же ты ВТ "мацаешь"?
Делаешь Выгрузить(), правильно? А не замечал, как эта Выгрузить() подтормаживает в отладчике?

(71)
Наменование основного средства не хранится в метаданных.
А из отладчика, сюрприз!, видно.
И дальше можно плюсиками раскрывать до чего угодно.

http://xn----1-bedvffifm4g.xn--p1ai/articles/временные-таблицы-3-вопроса/

Если Вы используете объект МВТ, то временные таблицы рекомендуется удалять одним из первых 2 методов, как только в них отпала необходимость, иначе они будут висеть в памяти сервера СУБД, пока процедура/функция не закончит работу, что не есть хорошо   Источник: ©Курсы-по-1С.рф

(73) то о чем ты говоришь это реквизит, а Имя справочника это таки его метаданные.

(76) Тебе сказать по теме есть чего, кроме шокирующих открытий, что Имя справочника это оказывается таки его метаданные?

(76) правильно, реквизит хранится в СУБД, но его можно посмотреть в отладчике

(74) все. тему можно закрывать.

(63) ошибаешься

(46) Да ладно а что тогда в ассемблере loop?

(68) Хотя могли бы сделать через курсоры...

Я отвечу - "Просто удобно"

(82) курсоры это совсем другая тема

(17) если ты свой код собираешься поддерживать и вносить исправления - делай всегда отдельные запросы.
если пишешь код "на от@@ись" - пиши один запрос с кучей пакетов. так в нем будет сложнее разобраться.

Не понял проблемы.  Нужны пакетные - делаешь. Не нужны - не делаешь.

От себя: мне еще ни разу не понадобились.

(85) (86) спасибо за мнение от представителей радикальной фракции

(86) ты наверное и писать то их не умеешь

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

(27) А БезЦикла(1000000) что дает?

(34) А в других кругах перейти - единственный вариант ветвления. А за рекурсию без необходимости бьют везде.

(90) см (50)

(91) а можно пример когда перейти - единственный вариант ветвления?

(63) Не рекомендуется, но используют. Даже инопланетяне (создатели типовых).

(93) В микроконтроллерах нередко бывает что только jump по условию и есть.

(95) вот это ты сейчас к чему вообще сказал?

(96) Привел пример других кругов.

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

(98) вопрос больше не про временные таблицы, а пакеты, которые могут быть и без временных таблиц

(99) ну т.е. когда запросы в пакете в общем то независимы друг от друга по больешй части, и потом разбираются через РезультатЗапроса[номер пакета]?
тут я бы посетовал на то что рпхост несколько раз будет общаться с субд и передавать тудой-сюдой данные. и лучше бы один раз получить их все. накладные расходы на каждый запрос так и сяк выше чем на один пакет.
но кого нынче волнует оптимизация. лучше купить ссд, нарастить оперативку, да камней побольше, ПОБОЛЬШЕ!
p.s. в отладке пакет с независимыми запросами ну ничуть не сложнее чем просто кучка запросов.

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

(99) Пакет с временными таблицами - зло. Ведь в результат запроса попадут и все временные таблицы. Даже уничтоженные (уничтожение, кстати, тоже даст элемент в массиве результатов).

(100) неверно
выше уже обсудили это

(102) Это будет список "указателей". И твоё дело уже выгружать данные с базы данных или нет. Так что это не ужас, ужас, ужас...

(104) Дык ресурсы сервера БД они занимать все равно будут. Даже когда уже не нужны от слова "совсем".

(105) Ну удаление есть временных таблиц в запросе. Можешь уничтожить объект пакет. А что ты считаешь что запрос ничего не потребляет? Понятно что для пакета требуется больше ресурсов, чем последовательное чтение того же самого. Но как я уже говорил выше, что есть случаи когда есть общие данные для последующей выборки разных данных это несколько ускоряет.

(106) > несколько ускоряет.
что замеры показывают?

(86) много теряешь

(106) Дык удаление в пакете оставляет данные временной таблицы. Поэтому и требуется схема с менеджером временных таблиц, когда на первом этапе готовятся все нужные временные таблицы, на втором этапе выполняется пакет, далее все временные таблицы убиваются, и на сервере остаются только нужные нам результаты запроса. Более того, эта же схема не сбивает нумерацию результатов запросов, потому как новый запрос добавляется в конец, а все требуемые для него временные таблицы выбираются на первом этапе.

(85) Вообще полный бред. Один текст запроса удобней для поддержки и дальнейшей разработки, чем портянки, склеенные в коде. Текст я беру целиком, иду в консоль запросов, там его дорабатываю, потом возвращаю все назад.
С лоскутной портянкой текста запроса, надо перед его выполнением смотреть Запрос.Текст только во время отладки. Потом после доработки сравнивать старую версию текста запроса с новой, а уж потом в лоскутки текста запроса вносить изменения. Трудоемкость возрастает как минимум процентов на 50.

(109) > удаление в пакете оставляет данные временной таблицы
Откуда информация?

(111) Он говорит о наверное о кэше данных в MS SQL :)
(107) Это логический вывод. К примеру ты фильтруешь контрагентов в зависимости от условий. И тебе нужна сальдо ( дебиторка ) по этим контрагентам так же последние операции по нему, а так же отдельно выписки. Это всё выгружается к примеру в личный кабинет клиента в различные структуры, к примеру csv. Это простой пример, бывает таблица, на которой в последующем строятся различные отборы вычисляется сложнее. Можно конечно через менеджер временных таблиц, только зачем? Тебе нужно всё вычислить и выгрузить и больше тебе не нужно иметь таблицу-основу последующих воборок. Последующие соединения могут идти в принципе параллельно. Сетевое взаимодействие с сервером базы данных в пакетном режиме может происходить быстрее, так как нет сильного разнесения по времени. К примеру выполнил пакетный запрос и что-то крутишь, вертишь, ну а позже запросил данные. За это время данные успели испечься.

(0) Когда в 8.1 появились пакетные запросы, временные таблицы и индексирование колонок в таблице значений - я плакал от счастья!

(112) это все слова, нужны замеры

(114) Замерь

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

(116) А сервер баз данных как фокусник тебе данные мгновенно отдаёт? Если у тебя запрос к таблице с миллионами строк что тогда?

(117) не понял вопроса в контексте обсуждаемой темы

(0) Вижу. Быстродействие.
Всегда имеет смысл их использовать хотя бы потому, что вложенные запросы усирают читабельность запроса в край. И работают часто гораздо медленнее, чем соединения с временными.

ОФФ: Люблю такие ветки. Столько умных людей собираются в кучу)) Это как про типовые втирать.

(119) Кстати, MS SQL научился (не знаю в какой версии) передавать параметры отбора во вложенный запрос (как СКД прям), так что самое время прекращать любить временные таблицы

(121) а как же postgres и курс на импортозамещение?

(121) за вложенные запросы надо по рукам линейкой бить

(123) Тут ты не прав, всё зависит от рук их готовящих. Никто ещё не отменял правило думать головой, а думать головой помогает теоретическая подкованность в данной области.

(123) так-то любой запрос к таблице остатков - вложенный. переписывать все на физ.таблицы теперь?

(111) Из опыта. Попробуй выбрать данные из уничтоженной таблицы.