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

(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) Не только слышал, но и пишу об это м в след. предложении, если ты не заметил. Минимальный анализ текста все равно выполняется, прежде чем обратиться к кэшу.