В самом деле, пару раз слышал, что это - плохо. Но вот пример! Допустим, надо получить из регистра сведений ЦеныНоменклатуры цены по всей номенклатуре и нескольким складам.
Номенклатуру-то одним запросом выдернуть не проблема, но вот по каждому складу надо свой запрос формировать. То есть, во-первых, это необходимо, а во-вторых, ничем не плохо. Говорят, якобы тормозит сильно, но у меня выполняется моментально.
Зачем огород городить с запретом запросов в цикле?

(0) Это смотря какой запрос, и какой цикл :)

(0) Если не критично то можно юзать запрос цикле.
А вот если все можно одним запросом вытащить потом просто юзать почему бы не сделать?

(0) По каждому складу тоже не проблема. Проблема когда запросы уж очень сложные. Тогда их построение вызывает вопросы.

(0) Достаточно сделать замеры, чтобы определиться. Зависит от конкретной базы и её заполненности.
Огород делают, чтобы его не затоптали. Если некому топтать, то можно и без огорода.

Если циклов 1-2-3 Ну пусть даже 10 раз и это оправдано логикой обработки данных запроса то можно.
А вот если у тебя в цикле уже 100-200 раз запрос с неким параметром отбора то это гов-код. Стыдно за такое.

Из любого правила есть исключения. Не стоит повторять это как мантру "запросы цикле запрещены...запросы в цикле запрещены". Но у автора похоже не этот случай:)

(2) Внезапно, запрос в цикле может оказаться быстрее одного запроса :)

(0) Он плох тем, что те, кто задает такие вопросы, обычно получают медленно работающий код через 1-2 года эксплуатации базы. Или раньше.

(8) Или не получают. Зависит от запроса. И от цикла. )

(7) Нет
Правильный запрос в цикле может оказаться быстрее кривого и запутанного одного запроса

Язык запросов прекрасно позволяет используя составные запросы и ВТ организовать цикл(ы) унутри субд

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

(9) Не, они - получают. Если только не в ларьке, где хватило бы Excel.

(0) Глянь план построения какого нибудь тяжелого запроса, который строит кластер к базе sql и умножь его она количество итераций. И тогда увидишь, что будет эффективнее - либо каждую итерацию строящийся план запроса, либо запрос к БД 1 раз.
Но тут правильно сказали, что все зависито от цикла и от запроса.

(14) Не корми

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

Кстати!

Когда в 1С появятся запросы на запись? Ну хотя бы для РС?

(11) Язык запросов позволяет положить sql-сервер соединением журнала проводок самим с собой без условия. Тоже неплохо.

(10) Не всегда можно для простого запроса для одного набора параметров построить эффективный запрос для нескольких наборов параметров.

Запрос в цикле обычно медленнее адекватного одного запроса.
Запретов нет прямых, можно использовать, но с оглядкой, что может просесть производительность.
Преждевременная оптимизация зло, но в 1С к коду редко возвращаются из-за оптимизации.
Если складов 5, то может и норм, а если это 100500 товаров, то нет.

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

(19) Это пока не умеешь в запросы

(17) Скорее всего никогда :(
Ведь должна же "бизнес логигка" отрабатывать.

(23) а как же случаи "ОбменДанными.Загрузка = Истина" ?

(24) Это просто пожелание. Некоторый код выполняется и в этом режиме.

(24)+ Да в РС можно прямыми запросами лить, но это не комильфо

(0) Тем, что возникает многократное обращение сервера 1С к СУБД.
Чаще всего подобное возникает в неявном виде - обращение к реквизитам объекта в выборке, которые можно было выбрать в основном запросе.

Есть вполне осознанное применение запроса в цикле - порционная обработка большого объема данных.

(17) Зачем?

(27) delete where как вариант

(26) например в узлах обмена не будет регистрации

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

(0) Как вариант - объединить тексты запросов, получится один запрос.

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

(32) Ты не путай
Аксиома это тоже вера
Использовать готовые формулы, которые придумали и проверили другие люди, без собственной перепроверки тоже вера

Вопрос только во что и кому верить
Умным людям или жрецам

(33) > и проверили
Вот тут как раз отличие веры от доверия

(34) корень то один и суть одна

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

с этой точки зрения запросы в цикле вполне допустимая вещь, если они не приводят к просадкам производительности и с ними получается более понятный и надёжный код

(35) слова похожие, а суть радикально разная

(37) https://www.translate.ru/перевод/русский-английский/?text=доверять%0Aверить

(33) и кстати аксиома, это не бездоказательное утверждение. Это утверждение типа "предположим, что ..." и далее на этом утверждении что-то строится. Никто не постулирует абсолютной истины в таких построениях.

(39) "предположим что высшая сущность есть" так?

(24) >> а как же случаи "ОбменДанными.Загрузка = Истина"?

Так в том то и дело, что ОбменДанными.Загрузка не отменяет полностью работу бизнес-логики. В коде может быть отключена только часть бизнес-логики по этому флагу, а может быть даже наоборот - настроено выполнение каких-либо дополнительных действий.
Если дать запросы на запись, то встанет проблема - как решать вопросы выполнения обработчиков событий объектной модели.
Не то чтобы это вообще невыполнимо. Но, как мне кажется, это неоправданно усложнило бы систему с соответствующим добавлением непредсказуемости и неконтролируемости.
Если сейчас, придя к заказчику и впервые увидев его конфигурацию, я точно могу быть уверенным, что при записи того или иного объекта отработает та или иная логика. То в случае наличия запросов на запись можно ожидать, что в любой момент в конфе может появиться какая-нибудь обработка, которая будет писать объекты напрямую в БД запросами в обход абсолютно любой логики.

(35)(40) Такое надо уже собирать на свой канал - https://youtu.be/orBGBSn6XRE?t=36

(28) Большинство 1С-ников запросы на выборку писать не умеют.

(40) да, вполне можно такое предположить

(22) Ну да, конечно :)

В общем очевидно что никто не смог толком сформулировать чем плохи зопросы в цикле.
Потому что на самом деле они вполне такие же.
Все перешли на высокие материи.

(44) аксиома :)

(46) См. (8). Использовать запросы в цикле может только тот, кто может обходиться без запросов в цикле.

(0) А почему для каждого склада отдельный запрос надо? Там разные поля нужны? Почему нельзя просто сделать группировку склад-номенклатура, и просто запрос обходить 2 циклами вложенными по складу, а внутри склада по номенклатуре? Как минимум в двойке видел такие запросы, в тройке, конечно, накрутили кучу ВТ...

(46)
"Стыдиться надо такие вопросы здесь задавать"
(С) dubolom, Посчитать сколько дней осталось дня рождения начиная с этого дня

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

но если запрос становится слишком сложным для понимания на несколько экранов это тоже плохо

(39) >> Никто не постулирует абсолютной истины в таких построениях.

Аксиома и постулат вообще-то синонимы.
Аксио́ма (др.-греч. ἀξίωμα «утверждение, положение»), или постула́т (от лат. postulatum — букв. требуемое), — исходное положение какой-либо теории, принимаемое в рамках данной теории истинным без требования доказательства и используемое при доказательстве других её положений, которые, в свою очередь, называются теоремами.

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

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

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

(0) Плох тем, что это потенциально узкое место, и если можно исправить, то нужно ;-)

(54) именно

и ни в коем разе не надо логику (алгоритм) кода делать на запросах в цикле
ибо будет сложно оптимизировать убрав узкое место

(46) Для очевидного есть ИТС: https://its.1c.ru/db/pubqlang#content:150:hdoc:_top:запрос%20в%20цикле ;-)

(0)Это не плохо, а неоптимально. Из аналогии, примерно тоже самое как поднять сразу много грузов в лифте на 10-й этаж и там спокойно все разгрузить или же носить пешком по одному грузу туда-сюда. Если позволяют время и средства, то пожалуйста)

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

Это всё лирика.
У меня прекрасно моментально работает запрос в цикле.

У профессионалов запросы в циклах не тормозят.

(59) А тут все надеются, что с ростом бизнеса перестанет :) А если бизнес уже не растёт, то и не перестанет :)

(59) Не у тебя одного.

(59) Попробуй взять базу хотя бы на 300-500 Гб.

(60) Профессионалы таких "обсуждений" не устраивают

(64) Профессионалы умеют делать замер производительности и смотреть план выполнения запроса.

(64) У меня есть 1с: Профессионал

(63) У меня база 12 ТБ... Не тормозят :(

Лучше бы провели опрос, где каждый должен привести конкретные примеры таких запросов чья производительность в цикле была бы хотя бы не ниже, чем решение аналогичной задачи одном запросом. С замерами и объяснениями.
А так получается какое-то бесконечное бла-бла-бла ни о чём.

(68) А смысл? Это будут специфические случаи, которые человек со стороны без погружения в контекст не поймёт.

(66) Я писал вопросы к тесту 1С Профессионал, а Вы засоряете форум глупыми ветками. Вам не стыдно?

(59)В 90% случаев можно сделать более оптимально)

(57) если время разноски одного пакета по этажу превышает время движения лифта и во время погрузки лифта все двери на всех этажах закрываются, то запрос в цикле норм.
Вероятно это вопрос блокировок, но это не точно.

(57) Хорошая аналогия )

Каждый месяц подобная ветка, запросы в циклах это плохо, но во всех типовых они есть в каждом документе. И вообще это беда всех ORM, orm - это там где обращение к таблицам идет через точку.

очередной клон Калимулина?

(73) а если лифтов больше чем грузов и носильщиков?

(59) Один?

Было лет 10 назад. Переносил данные из чужой нетленки в УТ 10.3. Клиенты и Организации были в одном справочнике, я переносил все и в Контрагенты, и в Организации, для последующего разбора и чистки.
Какой-то документ в УТ 10.3 не проводился, зависал. Стал разбираться. Нашел получение в запросе учетной политики, обращение было в цикле ко всем существующим организациям. Бессмысленно и беспощадно. Запрос переписал.

Получать данные запросом в цикле = плохо, а загружать, допустим, большой справочник с +100500 строками кода из подсистемы БСП (версионирование, новая RLS) = нормально. Тьфу.

(69) >> А смысл? Это будут специфические случаи, которые человек со стороны без погружения в контекст не поймёт.

Какие-то уж совсем специфические случаи наверняка могут быть. Но не так уж они и часты, как может показаться.
Сами объекты (справочники, документы, регистры и пр.) у всех абсолютно одинаковые.
И, по-моему, случаев запросов в цикле, обусловленных спецификой именно самого бизнеса совсем единичные случаи.

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

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

(70) Да лан, всем ведь весело вроде.

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

(68) ну и запросы у вас, батенька...
да если тут каждый начнет делать замеры и к ним объяснения - то кто трындеть то будет?!!

(0) Когда база маленькая и товаров с ценами мало, то без разницы.
А вот у меня была такая практика. Разрабатывали мы командой конфигурацию для энергоснабжения города 105 000 абонентов. Ну и минимум раз в месяц нужно было сделать расчет. Так вот даже относительно быстрый запрос по замеру производительности например 0.1 секунда, в цикле на 105 000 = выдавал уже 1050 секунд или 17.5 минут. Естественно приходилось писать везде писать код оптимизированный.

Так и типовые конфигурации, кто-то использует на 100 позиций, а у нас в базе сейчас номенклатуры около 700 000 штук. Поэтому и говорят, что нельзя запрос в цикле в типовых. Да и в принципе если не знаешь, до каких масштабов твоё решение вырастет.

(85) * ошибся я там 0.01 секунда, в цикле на 105 000 = выдавал уже 1050 секунд или 17.5 минут.

(0) На небольших объемах данных - ничем.

Как-то в начале 2000х писал конфу по ЗП на 1с77 в заводе.
Все с нуля. ЗиКа у нас не было.
Так вот какой-то у меня запрос и расчет длился 40 минут.
Я потом начали искать и оптимизировал что уже выполнялось в 2-3 минуты.
Как-то так.
Также не мало случаев было  и с запросами в цикле.

(76) "А если бы он вёз патроны?!"

(83) (84) Да понял я уже. Что никаких примеров не будет. А жаль. Было бы любопытно.
Всё с чем приходилось сталкиваться мне, это либо случаи когда разработчик посчитал нецелесообразным тратить время на усложнение кода ради копеечной выгоды в производительности. На небольших объёмах данных, значительный рост которых не ожидается в обозримом будущем, заметной разницы по скорости действительно может не быть. Либо массовые случаи одноразовых обработок, где производительность вообще никакого смысла не имеет, но важна скорость разработки и отладки.

(70) а какое у тебя место на инфостарте?

(0) никак не угомонишься?

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

На маленькой БД с оптимизацией на быстродействие можно не заморачиваться.

(94) + запрос в цикле - частая причина тормозов

(94) + а к большой БД не факт, что ТС когда-нибудь подпустят

(93) Да самый частый пример. Получить типовой функцией ПолучитьЦенуНоменклатуры() цены в цикле, а не думать надо запросом ))

(0) "но вот по каждому складу надо свой запрос формировать" - подскажите зачем?

(90) Вот вам пример из типовой УТ11. Здесь в цикле пытаются выполнить запрос, если не получилось то еще несколько раз пытаются)
    Пока Истина Цикл
        Попытка
            Результат = Запрос.Выполнить(); // Чтение вне транзакции, возможно появление ошибки.
                                            // Could not continue scan with NOLOCK due to data movement
                                            // в этом случае нужно повторить попытку чтения.
            Прервать;
        Исключение
            КоличествоПопыток = КоличествоПопыток + 1;
            Если КоличествоПопыток = 5 Тогда
                ВызватьИсключение;
            КонецЕсли;
        КонецПопытки;
    КонецЦикла;

(93) Когда пишешь какую-нибудь разовую обработку, чаще всего важнее написать её побыстрее, а производительность - дело десятое. И часто бывает, что в цикле запрос пишется гораздо проще.

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

(100) "в цикле запрос пишется гораздо проще" - в общем случае фиолетово. Можно писать без циклов в запросе.

(0) Ozon в своем расширении не стесняется по каждому складу в цикле номенклатуру отбирать, дабы остатки выгрузить по своему API. А им виднее))

Да, кстати, если кто-то вдруг решит внедрить расширение от Ozon, сразу блокируйте в нём запись в регистр Ozon_ПроблемыОбмена, потом спасибо скажете)

(102) Пример - нужно получить СрезПоследних на каждую дату в интервале. Оно запросом в цикле в несколько раз проще пишется.

(104) слишком много записей?

(100) >>  Когда пишешь какую-нибудь разовую обработку, чаще всего важнее написать её побыстрее, а производительность - дело десятое.

Это очевидный случай. И едва ли не самый частый. Я о нём в (90) написал. Он никакого интереса не представляет.
На одноразовых разработках все *авнокодят от души, наплевав на все правила и стандарты.

(106) ну зависит от количества товаров в выгрузке,  у нас 4к товаров за 2 недели сделали 29лямов записей в этот регистр, база на постгресс выросла на 25Гб.
Пришлось дропать регистр полностью и сжимать базу обратно) Тут был мой косяк, я сразу не настроил очистку этого регистра, а следовало бы.

(32) шедевр...

(105) И где дальше эти данные использовались?

(48) "самурай без меча - это как самурай с мечом, только без меча"

(105) Проще 1С не заниматься ;-)

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

(99) >> Здесь в цикле пытаются выполнить запрос, если не получилось то еще несколько раз пытаются.

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

(113) Хотя может быть ещё выгодно по-разному строить запрос исходя из значений параметров. Тогда цикл всё-таки может пригодиться.

(101) Хорошо, вот вам пример с контактами взаимодействий из той же УТ11

        РегистрыСведений.СостоянияКонтактовВзаимодействий.УдалитьЗаписьИзРегистра(Неопределено);
        
        Пока Истина Цикл
        
        Запрос = Новый Запрос;
        Запрос.Текст = "
        |ВЫБРАТЬ РАЗЛИЧНЫЕ ПЕРВЫЕ 100
        |    КонтактыВзаимодействий.Контакт
        |ПОМЕСТИТЬ КонтактыДляРасчета
        |ИЗ
        |    РегистрСведений.КонтактыВзаимодействий КАК КонтактыВзаимодействий
        |        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СостоянияКонтактовВзаимодействий КАК СостоянияКонтактовВзаимодействий
        |        ПО КонтактыВзаимодействий.Контакт = СостоянияКонтактовВзаимодействий.Контакт
        |ГДЕ
        |    СостоянияКонтактовВзаимодействий.Контакт ЕСТЬ NULL
        |;
        |
        |////////////////////////////////////////////////////////////////////////////////
        |ВЫБРАТЬ РАЗЛИЧНЫЕ
        |    КонтактыВзаимодействий.Контакт,
        |    МАКСИМУМ(Взаимодействия.Дата) КАК ДатаПоследнегоВзаимодействия,
        |    СУММА(ВЫБОР
        |            КОГДА ПредметыПапкиВзаимодействий.Рассмотрено
        |                ТОГДА 0
        |            ИНАЧЕ 1
        |        КОНЕЦ) КАК КоличествоНеРассмотрено
        |ИЗ
        |    КонтактыДляРасчета КАК КонтактыДляРасчета
        |        ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.КонтактыВзаимодействий КАК КонтактыВзаимодействий
        |            ВНУТРЕННЕЕ СОЕДИНЕНИЕ ЖурналДокументов.Взаимодействия КАК Взаимодействия
        |            ПО КонтактыВзаимодействий.Взаимодействие = Взаимодействия.Ссылка
        |            ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ПредметыПапкиВзаимодействий КАК ПредметыПапкиВзаимодействий
        |            ПО КонтактыВзаимодействий.Взаимодействие = ПредметыПапкиВзаимодействий.Взаимодействие
        |        ПО КонтактыДляРасчета.Контакт = КонтактыВзаимодействий.Контакт
        |
        |СГРУППИРОВАТЬ ПО
        |    КонтактыВзаимодействий.Контакт";
        
        Результат = Запрос.Выполнить();
        Если Результат.Пустой() Тогда
            Возврат;
        КонецЕсли;
        
        Выборка = Результат.Выбрать();
        Пока Выборка.Следующий() Цикл
            
            РегистрыСведений.СостоянияКонтактовВзаимодействий.ВыполнитьЗаписьВРегистр(Выборка.Контакт,
                                                                                      Выборка.КоличествоНеРассмотрено,
                                                                                      Выборка.ДатаПоследнегоВзаимодействия);
            КонецЦикла;
            
        КонецЦикла;

например, разузлование всех изделий из плана производства: либо запрос по каждому изделию в цикле, либо СКД с вложенной схемой..

(116) Здесь производительность приносят в жертву возможности переопределять функции (зайчатки ООП), кмк.

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

(116) Тут порции обработки таким образом реализованы.

(120) ага, как пример использования запроса в цикле

(105) "Пример - нужно получить СрезПоследних на каждую дату в интервале. Оно запросом в цикле в несколько раз проще пишется." - стандартный запрос. НИЧЕГО в цикле тут делать не нужно.

(121) Этот вариант выше писали.

Там, кстати, ошибка: выход из цикла если результат запроса пустой, а пустым он может быть и если все 100 контактов из временной таблицы при внутреннем соединении не соединились. В итоге цикл прерывается, а данные еще не обработаны.

(117) Вы просто не умеете его готовить: https://infostart.ru/1c/articles/158512/

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

(116) Тут видать они ждут что новые записи появятся, пока они обрабатывают? Иначе нафига вот это вот все?

(122) Ну, посложнее что-нибудь. Срез последних на каждую дату из каждого интервала, полученного из документа определённого вида, и сумма значений по каждому интервалу.

(125) Таблица договоров с задолженностями. Соединение с таблицей взаиморасчётов по договору условию РазностьДат>МаксимальноеЧислоДнейЗадолженности.
В чём проблема?

(125) Вместо запроса в цикле можно использовать запросы с передачей ТЗ

(125) >>  запрос по получению остатков по всем договорам по просроченным задолженностям (у каждого договора свое количество дней просроченной задолженности).

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

(127) Тоже не нужно запрос в цикле выполнять.
Единственное где в 1С придется выполнять запрос в цикле, это там где есть огромное желание выполнить рекурсивный запрос. Так как 1С в отличии от чистого SQL этого не умеет.

(131) Так и я говорю, что практически всё можно реализовать без цикла (обычно спасает передача ТЗ).
Но речь-то шла про одноразовые обработки, где чаще всего надо написать и отладить тупо быстрее.

WITH num(n) AS(
SELECT 0 as n
UNION ALL
SELECT t.n+1 FROM num as t

WHERE t.n <= 9)


select t.n from num as t

Вот это на 1С не напишешь....

(0) При сложных загрузках/выгрузках данных запросы в цикле - это единственный возможный вариант обработки данных.
В рамках одной ИБ вероятно можно обойтись без запросов в цикле. При обменах в нескольких информационных системах бывает других вариантов просто нет.

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

(132) Не всегда. Как-то надо было какой-то новый реквизит запомнить необходимо было значением по умолчанию. Ну так разработчики придумали - завели новый реквизит в давно существующий объект и по умолчанию он должен быть не нулевым. Средствами 1С в существующей базе данных такой реквизит заполнялся более 3-х часов. Средствами SQL на прямую за 3 секунды. Иногда проще сложнее что-то выполнить, но по временным рамкам на много быстрее.

(132) >> речь-то шла про одноразовые обработки, где чаще всего надо написать и отладить тупо быстрее.

Когда это мы вдруг решили ограничить тему одноразовыми обработками?
Я что-то пропустил?

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

(136) Это семёрка была и 1с++?

(126) Если записей много - там могут получаться миллиарды записей до наложения фильтра. А не все СУБД умеют накладывать фильтры запроса на подзапрос.

(137)
>Когда это мы вдруг решили ограничить тему одноразовыми обработками?
Не всю тему, а конкретно это обсуждение началось со (100).

(138) НЕТ.
В 1С++ можно писать в БД. Это была как раз 1С 8.0 или 8.1.

(131) Типовуха: получение всех вышестоящих подразделений.

(142) В общем случае, это как раз рекурсивный запрос.

(125) Аналог остатки/обороты на каждую дату. Кстати, тоже видел решения запросом в цикле (собственно один день = один запрос)

(142) Иерархия в 1С - это отдельная больная тема. Тут уж ничего не поделаешь. Даже сама 1С где-то рекомендовала получать всех родителей циклом, когда не известна заранее глубина вложенности.

(142) Если число уровней ограничено, то изи.
А оно обычно ограничено, крайне редко бывает больше 10 уровней вложенности, тем более у подразделений.

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

(145) Либо циклом, либо отдельный регистр для "обратной иерархии" - в зависимости от приоритетов.

(132) в (0) этого не было, что-то вы ТЗ на ходу меняете ;-) Гибкие технологии?

(149) Это обсуждение со (100) началось.

(146) Так-то может еще и история подчиненности подразделений быть. Плюс все это дело может быть в RLS засунуто...

(148) Можно ещё хранить глубину вложенности в константе. Это имеет смысл, если надо часто получать всех родителей у большого числа элементов.

(150) Еще чуть-чуть и перейдете на светлую сторону!

(100)
сами себе противоречите:
Вы писали
"   dubolom
18.11.21 - 14:25
Как вы для себя решаете этот вопрос?
Лично я всегда - исключительно за качество. Лучше потратить немного больше времени сейчас, чем потом тратить его на вылавливание косяков и доработки недоработанного.
Зато у меня всегда идеальный код."

(151) На стандартном SQL запрос в цикле для рекурсивного запроса с вложенностью менее 100 не нужен.
Это уже ограничения 1С.

(154) Это продолжение пятницы

(153) Я вообще на ней начинал. Решил тут вас развлечь немного, но походу всем надоело.

(0) > Чем плох запрос в цикле?
Да всем хорош. Только если есть возможность выкопать несколько ямок за один вызов экскаватора, то только дебилы будут вызывать экскаватор на каждую ямку.

(158) Но если вам надо сделать несколько ямок - то глупо рыть траншею экскваватором, а потом лишнее заваливать.

(159) Затрудняюсь определить, на какой случай это аллегория. Фильтрации в постобработке, что ли?

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

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

(162) Делайте. Но файл можно и в ТЗ прочитать ;-)

(162) Можешь за один запрос выполнить несколько работ - выполняй. Не можешь - не выполняй. https://youtu.be/hgJpWBSQvcQ

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

Обычно всегда можно найти возможности для оптимизации выполнения.
Стоит ли их искать в конкретных случаях - каждый решает сам. Тут уже опыт, сын ошибок трудных. И элементарный просчет ситуации хотя бы на пару шагов вперед.
Многие новички просто не просчитывают перспективу. То ли не хотят, то ли не умеют. Заработало? Устраивает? Готово, мастер!
С запросом в цикле основная ведь беда не в текущей эффективности. А в очень плохой масштабируемости. Может, она и не нужна. Но об этом надо хотя бы задумываться.
Обычно, если не семи пядей во лбу, то нужно хотя бы несколько лет поработать в активной разработке на своей же собственной кодовой базе в развивающейся компании. Желательно на немаленьких или хотя бы растущих масштабах. Тогда будет хотя бы возможность переломать ноги о собой же разложенные грабли. Если и это не научит (а многих таки не учит) - значит не в коня корм. Что уж тут попишешь.
Но если хоть капелька ума есть, то научишься просчитывать ситуацию и писать так, чтобы не затрачивая много времени избавлять себя от кучи проблем в будущем.

(166) 1с-ник может в любой момент уволиться и новую работу найти (по крайней мере, в миллионниках). Это здорово расхолаживает.

(0) У СУБД есть постоянные временные затраты на каждую выборку и переменные.
Запрос в цикле увеличивает сумму постоянных затрат. Запрос без цикла может увеличивать сумму переменных.
Надо балансировать для оптимального взаимодействия.

(168) *для оптимального быстродействия.

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

(170) например поиск верхнего родителя для элемента

У вас есть АПИ стороннего севиса, которое за 1 раз принимает одну номенклатуру с ценой. Пусть отклик оно дает через несколько секунд. Вы при любом раскладе будете дергать его в цикле по одной номенклатуре за раз. Вы можете одним запросом сформировать выборку для нескольких тысяч позиций номенклатуры и все равно дергать по одной штуке АПИ. При этом в памяти на клиенте/сервере (ОФ/УФ или как написали код) у вас будет храниться вся выборка и занимать память. А так ничего не случится если раз в несколько секунд будет выполняться небольшой запрос в цикле.

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

(173) Все верно, но я про однопоточное АПИ.

(173)+ в фоновых уже не будет запросов в цикле, просто циклы в которых дергает апи

(174) а где запрос то в цикле?
дергать апи в цикле и дергать запрос в цикле это две большой разница

(176)+ и да
Если у апи есть методы которые принимаю разом много номенклатур а не одну
Дергать в цикле однономенклатурный метод это изврат согласны?

(177) Вне сомнения.

(177) Разве что если ситуация не такова, что следующий запрос в апи зависит от ответа на предыдущий.

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

Как-то довелось наблюдать картину, как один любитель бездумно выполнять рекомендации угробил производительность, избавившись от цикла. Был запрос в цикле:

ВЫБРАТЬ ... ИЗ РегистрСведений.БлаБла Где Измерение1 = &Значение1 И Измерение2 = &Значение2 И Измерение3 В (&Значение3)

внутри цикла менялся параметр Значение1. Ну наш оптимизатор, не долго думая, выносит запрос за цикл и переписывает его так:

ВЫБРАТЬ ... ИЗ РегистрСведений.БлаБла Где Измерение1 В (&Значение1) И Измерение2 = &Значение2 И Измерение3 В (&Значение3)

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

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

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

(182) >>но не говорите это никогда когда будете сдавать любой экзамен фирме 1С

на экзамене фирмы 1с
https://disk.yandex.ru/i/CgB734tATmbBtQ

(182) >> но не говорите это никогда когда будете сдавать любой экзамен фирме 1С.

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

А эта ветка на протяжении почти двух сотен постов так и не родила ни одного внятного примера, где запрос в цикле был бы более целесообразен, чем один запрос, собирающий все данные сразу.
Всё свелось к примерам одноразовых обработок, где производительность никого не интересует вообще и когда на*авнокодить запросов в цикле тупо быстрее и проще, чем мучаться в припадках перфекционизма. А так же случаев, когда выигрыш в производительности не будет иметь никакого принципиального значения. Примеры циклов, которые вообще к запросу не имеют отношения, типа (99) я опущу.

1С же на экзаменах заранее озвучивает условия. И условия эти гласят, что вы как исполнитель не знаете о том насколько велика будет база данных, для которой вы решаете задачу, и сколько в ней будет работать пользователей и насколько она будет высоконагруженной. А значит решать задачу следует, исходя из необходимости написания самого оптимального, с точки зрения производительности, решения.

(185) > самого оптимального, с точки зрения производительности, решения.
Вот только оптимизация эта, она субъективна. Я, например, точно также не знаю ресурсов компьютера, для которго я решаю задачу и поэтому во исполнение https://its.1c.ru/db/v8std#content:725:hdoc я буду запрашивать данные порциями фиксированного размера. В цикле, естественно.

(108) Он совсем не нужен?

(186) Здесь ведь речь о выборках, которые потенциально могут иметь очень большой размер.
Случаи такие встречаются редко, но вполне возможны.
1С эти свои рекомендации из статьи по ссылке регулярно применяют в типовых конфигурациях. В обработчиках обновления, где производится массовое перезаполнение каких-либо объектов или регистров, - постоянно.
Но опять таки в экзаменационных билетах что-то я не припомню задачи типа "перезаполните по определенному алгоритму все счета-фактуры в базе или какой-нибудь регистр".
Думаю, автор ветки всё таки имел ввиду случаи, когда речь идёт о многократном повторении в цикле одного и того же запроса, а не об организации цикла ради порционной обработки огромных массивов данных.

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

Но,во взрослом sql есть описание запроса prepare и исполнения execute.
Правда,если создать запрос и определить его текст за пределами цикла,то утверждается,что будет выбран именно этот вариант,исключающий повторное постррение плана запроса.

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

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

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

Когда нашу фирму перевели с самописок на 1С УПП (это было в 2007) перед франчами поставили задачу - написать обработку автоматического выставления документов. Типа раз в месяц из сторонней организации приходит эксел-файлик с списком какая организация сколько запланировала потребить газа в следующем месяце. Нужно им выставить счета на оплату, РТУ и СФ.

Нужно учесть факт за прошлый месяц и кучу-кучу отдельных условий-соглашений который возможны как с группой потребителей так и с конкретной фирмой :-)
Франчи напыжились и выдали обработку. Только вот суммы почему-то никак не сходились с тем, что бухгалтерия отдельно рассчитывала. Т.е. в какой-то месяц сходилась - а в какой-то месяц нет :-)

Сию задачу перекинули на меня с требованием "чтоб всё стало сиська в сиську !!!". И это были мои первые знакомства с 1С...

Посмотрел я обработку. А там сперва офигенный запросище (это было 8.0, временных таблиц ещё не было). Т.е. практически всю логику в стиле "если так то делай так" они пытались реализовать в это запросе. А потом цикл и большая-большая куча кода прямо в этом цикле :-)

Я же как программист "в языках" привык разбивать "по функциям". Каждой функции - своё маленькое дело. Функции максимально изолированные, ну и т.д.
Собственно я взял и целиком всё переписал в этой парадигме. Если функции были нужны данные - она их получала через запрос.

Мало того что всё заработало правильно - оно ещё и сильно быстрее. Типа функция получает параметр - контрагента. Определяет был выставлен СФ или нет коротким запросом по документам СФ с отбором по Контрагент и интервалу дат.

Когда я обработку показал тем франчам они сказали что я чуть ли не преступление написал - ведь там "куча запросов в цикле" :-)
Они предавали этому факту странную для меня гигантскую важность а я не мог понять что за бред они несут. Я говорил - "смотрите, У МЕНЯ ВСЕ ОТБОРЫ ПО ИНДЕКСАМ" ! Ну привык я сам проектировать базы так, что отборы постоянно были по индексам...

Потом Я посмотрел код типовых и прифигел ещё больше. Тип - "вот мы получаем данные в ТЗ, а эти данные в другое ТЗ, упаковываем в структуру и раздаём по функциям. А в каждой функции мы вытаскиваем ТЗ обратно и ищем отборами по нужным нам параметрам уже в этих ТЗ". Мне была не понятна природа этого извращения...

Но потом я поработал с 1С побольше, привык и перестал удивляться. Видимо, произошла "смерть программиста и рождение 1С-ника" :-)

Простите за глупый вопрос, а в файловой базе индексы есть?

+или в связи с увеличением мощности компьютеров это уже неактуально?

(193) никакая мощь компьютеров не позволит обрабатывать всю базу по 100 раз в секунду

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

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

(185) вам нужны примеры? Чужой код... запрос в цикле... но работает правильно и не создает проблем - да и пусть!

(100)
>> // Could not continue scan with NOLOCK due to data movement


Занятно.

Этот код устарел примерно с перехода на режиме совместимости 8.3.2 (и выше).

И это код от фреша на самом деле, то что он живет в УТ (как и в остальных типовых которые есть на фреше) - просто такой способ распространения.

(196) Да, тут фишка в том что 1С-ник обычно работает с типовыми и не может расставлять индексы под задачи своей фирмы.
Возможно отсюда идёт эта "выгрузим большим запросом в ТЗ и будем с ней работать".

Кстати как правильно, индексация или индексирование?

(196) В клиппере была команда Scan... запросы в фоксе про работали и на безиндексных dbf, насколько помню

(200) вроде аналоги-же

Точно, говорили, если что-то...., то база упадет в скан.

(201) Или просто типа SET FILTER KOD=100...

Но seek по индексу был чудно быстрее... :-)

(204) если попал в индекс - моментально

Почему в 1с индекс назывался CDX, а не IDX?

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

(206) Потому что idx это индекс в отдельном файле, а cdx это файл, в котором несколько индексов, относящихся к основной таблице. В фокспро было так же.

(205) Да, скорость была просто восхитительной - никто и не думал "экономить на запросах в цикле" :-)

Ещё прикол. Оказалось что Access как и VB позволял работать с данными в формате mdb в таком же стиле, без запросов - через seek (это было ещё до ADO). И скорость была тоже изумительна.

Помню, я благодаря этому просто "влёт" перевел приложение с клиппера "в виндовс" - логику менять вообще не пришлось...

В фокспро и клиппер seek - команда поиска по индексу, locate - команда поиска без индекса

И как сейчас в 1с 8 первая помощь - чистка кэша, так и в 7ке переиндексации или пересоздание индексных файлов.

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

(197)  >> Чужой код... запрос в цикле... но работает правильно и не создает проблем - да и пусть!

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

(212) В 1с следовало бы ввести возможность в конфигураторе создавать произвольные индексы. Очень не хватает этой функции. Индексирование по умолчанию не гибко.

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

Сомнительное утверждение. Нигде не встречал подобной трактовки.
Доподлинно известно, что если определить текст запроса за пределами цикла, то это избавит платформу от необходимости анализировать синтаксис текста запроса в каждой итерации цикла.
У 1С даже соответствующие рекомендации есть. Типа если избежать запроса в цикле невозможно или слишком сложно, то определение текста следует выполнить до цикла.

(212) Ну, например так.
Сперва делаю запрос где получаются нужные данные которые запихиваются во временные таблицы с нужными индексами.
А потом спокойно пишу "много маленьких функций" где каждая функция получает данные из созданных вт по индексам, адаптированным к данной задаче.

Менеджер можно сделать глобальным уровня модуля (чтобы не передавать как параметр в каждую функцию) и явно грохнуть его когда станет не нужен типа МенеджерМоихТаблиц = Неопределено

В типовых везде ПолучитьРеквизитыОбъекта используется - это они так запросы в цикле от любопытных глаз прячут.

(217) Получение реквизитов объектов при их обработке в цикле - неизбежное зло. Всех данных заранее не запросишь и не получишь. Особенно, когда заранее неизвестно - что именно может понадобиться.
И т.к. в общем случае получение данных запросом менее накладно, чем при использовании объектной модели (через точку от ссылки), то приходится пользоваться этой функцией из БСП.
Хотя тоже не всегда это оправдано, а иногда ничего страшного нет в том, чтобы получить весь объект целиком. и это будет менее накладно, чем 33 раза запросом получать его реквизиты и данные табличных частей.

(218) Мне кажется лучше всего так. Вот есть процедура которая выполняет некоторое действие получая параметр Ссылка типа РТУ.
В голове функции делаем запросик где получаем нужные данные. А потом работаем только с ними.

Понадобилось что-то ещё - добавили в запросик. Ляпота.

А с помощью ПолучитьРеквизитыОбъекта  я получу структуру с нужными мне реквизитами, такими как Контрагент. Но вот ИНН этого контрагента - уже нет. Или "через точку" или снова ПолучитьРеквизитыОбъекта.

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

(220) Да нет, индексирование всё равно "очень".

Пример - работает база УПП, в ней одновременно куча пользователей работает с одними и теми же таблицами.
И индексы очень даже "очень".

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

(215) анализ синтаксиса выаолняется при первом выполнении запроса.

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

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

(223) "Не забываем,что в sql есть даже отдельная команда обновления индексов,т.к.новые данные попадают в индекс не сразу."
Это не так. Данные попадают в индекс сразу же по мере их добавления/обновления. Другое дело, что они могут лечь в индекс в неудачном порядке, что ухудшит поиск в худшем случае до линейного (теоретически).

(222) >> анализ синтаксиса выполняется при первом выполнении запроса.

Если текст запроса определен перед циклом, то да - один раз.
Если в цикле определяется текст, то анализ синтаксиса и перевод его на язык СУБД буде производится каждый раз. Хотя не исключаю, что может быть с момента написания статьи (ссылка ниже) что-то и поменялось.

https://its.1c.ru/db/pubqlang#content:150:hdoc:_top:запрос%20в%20цикле
Но иногда требуемое условие запроса, позволяющее отказаться от выполнения в цикле, сформулировать бывает затруднительно или очень сложно. В этом случае как минимум нужно вынести создание запроса за пределы цикла, а в цикле изменять только параметры запроса. Это позволит избежать многократной синтаксической проверки текста запроса (листинг 4.8).

То есть синтаксис проверяют по команде запрос.текст? А не запрос.выполнить()?

(226) Уточнять это надо у разработчиков платформы.
Вероятнее всего, синтаксис впервые проверяется в момент Запрос.Выполнить(). Но если в дальнейшем Запрос не переопределяется и изменения текста запроса не происходит, то и синтаксическая проверка повторно не производится.

Думаю как-то так.
Потому что при первой установке значения Запрос.Текст зачастую туда пихают текст к таком виде, в котором он выполниться не смог бы. А потом походу выполнения кода этот текст корректируют в зависимости от каких-либо условий.

(223) > в sql есть даже отдельная команда обновления индексов,т.к.новые данные попадают в индекс не сразу.

Это что-то новенькое. Что за трава^wкоманда и с какой версии появилась?

(225) (227) Хочу напомнить, что 1С все запросы выполняет через sp_executesql(). Поэтому анализ текста запроса производится каждый раз. А вот построение плана запроса выполняется не каждый раз, но и не гарантированно один раз. Тут 1С полностью полагается на механизмы кэширования запросов скуля.

(0) Запросы в цикле не совсем хорошо и не совсем плохо. Они действительно необходимы только в том случае, когда по - другому не сделать. Все зависит от конкретного уровня задач и решения. Но в целом считается немного иначе, что запросы в цикле плохи, когда данных много. Когда конфигурацию пишут прикладные программисты (тоесть разрабатывая типовые механизмы) то упор идет на масштабируемость и  всемя способами стараются прибегнуть к правилу запросы в цикле это плохо. Но при адаптации собственных решений под конкретные задачи - это совершенно другое и все зависит от условий.

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

(229) >> 1С все запросы выполняет через sp_executesql(). Поэтому анализ текста запроса производится каждый раз.

Есть подозрение, что мы говорим о разном.
Ты под анализом текста запроса понимаешь анализ текста на стороне СУБД. Разумеется там анализ текста производится каждый раз.
А в статье на ИТС по ссылке из (225) речь идёт о синтаксической проверке теста запроса на стороне 1С. Еще до того, как выполнить sp_executesql().
Иными словами, если запрос и его текст определены перед циклом, то проверка текста запроса сервером 1С будет выполняться только один раз (перед первым sp_executesql()). И если объект "Запрос" и его свойство "Текст" в цикле не меняются, то повторно текст запроса не анализируется, а передаётся в первоначальном виде. Если же внутри цикла объект "Запрос" создаётся каждый раз заново или меняется его свойство "Текст", то сервер 1С тратит какие-то ресурсы в каждой итерации на анализ текста запроса перед тем как выполнить sp_executesql().

(229) "1С все запросы выполняет через sp_executesql(). Поэтому анализ текста запроса производится каждый раз"
нет. Про кеш запросов ты не слышал, вероятно...

(231) это оптимизация на спичках.

(233) >> это оптимизация на спичках.

Не спорю.
Но вряд ли 1С-ники совсем уж просто так включили упоминание этих спичек в свои рекомендации на ИТС.
Когда речь идёт о тысячах итераций, расходы могут быть заметными.

(232) Не только слышал, но и пишу об это м в след. предложении, если ты не заметил. Минимальный анализ текста все равно выполняется, прежде чем обратиться к кэшу.