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

>Запрос в цикле. Когда он выгоднее, чем запрос вне цикла?

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

(0) в комплексе с другими моментами когда количество итераций цикла известна заранее и решение того стоит

(1) неправильный ответ. в моем случае выгоднее именно в цикле. ибо сумма квадратов всегда меньше квадрата суммы

(1) >> Правильный ответ - никогда.
А обоснования данного тезиса у Вас есть?

(0) Например, запрос вызывается с такими разными наборами параметров, для которых неэффективно получать всё в одном запросе.

+(4) (1) Вы просто не умеете их готовить (с)ВР

(3) Не понимаю причём тут это.
(4) Конечно. Как минимум не тратится время на иннициацию запроса, передачу параметров и т.п.

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

Т.е. если я устрою цикл из 4-х элементов (УУ, БУ, НУ, МУ) и далее отдельно формирую запросы к разным данным, я не считаю это "запросом в цикле".

(7) >> я не считаю это "запросом в цикле"
о как.., тут - это запрос в цикле, там нет
Еще один пример: получение различных начислений по сотруднику так же не не запрос в цикле?

(0) Запрос в цикле практически всегда лучше, чем решение той же задачи через запрос вне цикла.
1. Лучше использовать явный цикл, чем неявный. Это понятнее и нагляднее.
2. Оптимизировать надо там, где есть потребность в оптимизации.
3. Незачем потакать лени разработчиков платформы. В чем проблема выносить запросы из циклов на уровне платформы? Разве не этим она должна заниматься?

(0) Когда есть составное поле и ты не знаешь все его типы до выполнения запроса.

(10) Плюсану. Только что об это подумал

(9) вам лучше продолжать писать в политике.

(8) Хорошо скажем так, я под "запросом в цикле" подразумеваю один и тот же запрос (или с очень минимальными правками) в который передаются разные параметры, перебираемые в цикле. Т.е. цель цикла - именно в переборе параметров.

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

(13) так точно -> (2) + (6)
Но однозначно сказать что запрос в цикле это плохо - нельзя!

(14) У большинства другое мнение)

(0) Он выгоднее тогда, когда надо решить задачу, но ты не знаешь как сделать без него.
(10) Надо строить запрос кодом.
(9) Я надеюсь это ты тралишь, а не выражаешь свое профессиональное мнение.
Однозначно, выборка  данных единым запросом лучше, чем дергание СУБД постоянными запросами поменьше, ибо возрастает вероятность блокировок.

(16) В смысле - запрос - кодом?

Я вот про это:

Выбрать Продажи.Регистратор.Номер как НомерДокумента
из РегистрНакоплений.Продажи как Продажи
Где Продажи.Период>&НачалоМесяца

его нужно заменить на
Выбрать Продажи.Регистратор как НомерДокумента
из РегистрНакоплений.Продажи как Продажи
Где Продажи.Период>&НачалоМесяца

и постобработкой получить номера, с числом запросов= количеству различных типов регистратора.

(17) Всмысле в зависимости от входных данных (например, анализа метаданных) строишь тело запроса. Что-то мне не верится, что для тебя такое в новинку

(18) В зависимости от типов своих регистраторов делаешь

Выбрать ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.ТВОЙ_ТИП_ДОКУМЕНТА).Номер как НомерДокумента
из РегистрНакоплений.Продажи как Продажи
Где Продажи.Период>&НачалоМесяца
ОБЪЕДИНИТЬ ВСЕ
и тд и тп

(20) Откуда ты узнаешь, какие типы регистраторов попали в выборку ДО выполнения запроса?

Выбрать ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.ТВОЙ_ТИП_ДОКУМЕНТА).Номер как НомерДокумента
из РегистрНакоплений.Продажи как Продажи
Где Продажи.Период>&НачалоМесяца
ОБЪЕДИНИТЬ ВСЕ

легко заменяется на


ВЫБОР КОГДА Продажи.Регистратор ССЫЛКА Документ.ТВОЙ_ТИП_ДОКУМЕНТА1 ТОГДА
ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.ТВОЙ_ТИП_ДОКУМЕНТА1).Номер
КОГДА Продажи.Регистратор ССЫЛКА Документ.ТВОЙ_ТИП_ДОКУМЕНТА2 ТОГДА
ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.ТВОЙ_ТИП_ДОКУМЕНТА2).Номер

(21) Хорошо. Если у тебя такая задача, то держи.
1. Кодом получаешь типы регистраторов.
2. Строишь запрос.
(22) Да, можно и так.

(23) Каким кодом?

(23) "Да, можно и так."

Весело там у вас.

(24) запрос для поисковой машины: "Как получить типы регистраторов в регистре накопления"

(25) Вот тут не совсем понимаю. Хочешь сказать, что case сильно оптимальнее union?

(26) Ты прикалываешься?
Еще раз вчитайся внимательно во фразу
"Откуда ты узнаешь, какие типы регистраторов попали в выборку ДО выполнения запроса?"

(28) ХЗ, может ты прикалываешься? У тебя нет доступа к РН до выполнения запроса?

(27) union потребует x поисков по таблице, где x - количество типов регистраторов с последующим merge

(30) Ты вроде с планами дружишь. Можешь быстренько глянуть? Я просто, утверждать не берусь, но подглядел такие union на взрослых системах еще во времена обучения.

(29)
с 1 января по 31 января были только ПТУ.
1 февраля были только РТУ.
У нас выборка с 2 февраля.
Вопрос - надо ли трогать таблицу ПТУ?

(32) А что-то изменится, если в union all попадет выборка из РН по типу регистратора, которого нет за это период?

Вот жесть жеж.

(34) Не ну тебе виднее, ты же собак много съел на запросах.

(34) Мне просто нравится твоя жесть. Вытащить регистраторы запросом, а потом из выборки вытащить типы регистраторов, а потом построить запросы.

(36) Рекомендую собрать план запроса в какой-нибудь ERP для

ВЫБРАТЬ ПЕРВЫЕ 10
    ДвиженияСерийТоваров.Регистратор.Номер КАК РегистраторНомер
ИЗ
    РегистрНакопления.ДвиженияСерийТоваров КАК ДвиженияСерийТоваров

(0)Когда есть уже готовые запросы и их вызовы не создают видимые тормоза. Лучше использовать уже готовые запросы как например ПолучитьЦену() чем каждый раз клепать что-то свое. Все пишут запросы в цикле, странно, что кто-то еще говорит: "Запросы в цикле - зло".

(38) Странно это не понимать и не стараться избегать всеми силами.
Там только на передаче данных туда-сюда между сервером 1С и sql сервером куча накладных расходов.

(39) https://youtu.be/aKrMQzfgpVg

(39) https://youtu.be/yIioEpPyuzs

Критикуешь - предлагай?!
Несомненно:
https://youtu.be/fEYceCWI_h0

(37) У тебя вроде маркировка больная тема, отсюда и отсылки к своим любимым сериям. Но я человек простой, запросы строю за деньги.
(40) , (41) , (42)  Ты уже принял писят грамм "чтобы спалось лучше"? ))

(37) И да, традиционно: опиши задачу, возможно ты решаешь ее не правильно.

(36) >Вытащить регистраторы запросом, а потом из выборки вытащить типы регистраторов, а потом построить запросы.
(43) >У тебя вроде маркировка больная тема, отсюда и отсылки к своим любимым сериям. Но я человек простой, запросы строю за деньги.

Типовые конфы, метаданные сильно не исправишь, приходится выкручиваться чем можно.
Ибо работать то надо на то что есть.

(45) Можно денормализовать, но устроила постобработка.

(46) Блин напомнил про хитрый хак.
Когда вместо исправления головоломного запроса на несколько экранов.

Тупо и банально после него подсовываем (в т.ч. кодом) что надо для отчета.

(47)+ В результат после выполнить подсоваем

(48) тьфу *подсовываем или изменяем данные как надо.

(47) Да все мы, бывает, говнокодим.

(50) нет.

(39)Избегать запросов в цикле?

(51) Ой не смеши.

(16) Я вроде бы достаточно ясно выразился.
Простота кода важнее производительности, которую, в идеале, должна обеспечивать платформа.

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

(54) ты это пользователям потом расскажешь, которые спросят за тормоза

(55) пример не совсем корректный ибо он изначально запросом не решается

(57) http://catalog.mista.ru/public/158512/

(58) Я знаю эту тему, пробовал собирать запросом, по скорости полный трэш, собрал программно в 20 раз быстрее.

(59) Ну так palsergeich и написал что быстрее ) Но ведь можно же.

В чем заключается выгода?)

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

Когда делаешь запрос в цикле - ты можешь легко оценить оставшееся до завершения алгоритма время. В случае же, если мегазапрос выполняется sql-сервером, ты не видишь никакого прогресса, программа тупо "висит". Для пользователя приятнее видеть прогресс-бар минуту, чем полминуты зависшее окно.

(0) Когда необходимо ограничить размер выборки и обрабатывать по частям:

<CODE>
ВЫБРАТЬ ПЕРВЫЕ 1000
...
</CODE>

Выгоднее в случаях:

1) Алгоритм будет использоваться редко (какая-нибудь разовая обработка, отчет, запускающийся раз в полгода).
2) Количество циклов предсказуемо и небольшое (например, количество районов в городе 4-5) и не влияет особо на скорость исполнения алгоритма.
3) Разработка более сложного кода (без циклов) будет более затратна, чем эффект от экономии использования более оптимального кода.

(0) Есть ситуации, когда запрос в цикле не выгоднее, а единственно возможное решение. Например разузлование спецификации номенклатуры или построение дерева затрат без СКД.
Может я конечно чего-то не знаю, поэтому если есть способ без цикла и без СКД, то прошу поделиться.

(62) включи ему gif-ку

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

А что насчет запросов в цикле из временных таблиц?

Запрос в цикле допустим, если он:
а) не губит производительность
б) делает код проще и удобочитаемее, по сравнению с запросом "по феншую"

(65) скд теже циклы крутил. или раз я не пишу слово цикл - значит я молодец?

Была ситуация (правда еще на 8.1 и 8.2) когда выборка более 1млн записей падала. А поскольку требовалось сформировать данные за месяц (порядка 20млн записей), то приходилось разбивать месяц по периодам и формировать кусками.

а давате похоливарим на тему запросы в цикле от разработчиков типовых?

(69) если (а) никогда не выполняется, смысл писать про (б)?

(71) зачем нужна выборка на 1млн (или темболее 20млн) записей? Что с ними делать?

(73) в каком смысле не выполняется? У производительности тоже есть границы разумного. Допустим, в справочнике заведомо 100 элементов, за раз нужно получить 5 элементов. Тут совершенно пофиг, как ты там будешь получать эти данные из справочника, хоть через точку, хоть запросами в цикле, хоть "оптимальным" запросом, ибо всё оно будет выполняться моментально. Ну перепишешь ты запрос оптимально, выиграешь 0,00003 секунды, а пользователь этого никогда не заметит. Что это даст?
В то же время попытки получить данные одним большим запросом заведомо усложняют решение.

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

(75) ок, тогда пункт (а) из (69) нужно разворачивать - "..., в границах разумного". Только у каждого свое понимание разумного. Какое понимание, допустим, у экзаменаторов 1С?

(76) ты мне про (74)?

(77) у экзаменаторов 1С какие-то свои представления о производительности. "Вот вам база из двух справочников по три элемента в каждом, пишите оптимальные запросы"
пункт (а) из (69) разворачивать не нужно. Затраты в лишние 0,005 секунд на всю операцию субъективно никак не влияют на производительность. Такого "ухудшения производительности" никто и никогда не заметит. В то же самое время, не рентабельно тратить часы на оптимизацию и делать код менее читабельным, ради сомнительного выигрыша в 0,005 секунд. Всегда должен быть баланс между "легкостью" и производительностью кода

(79) 0.005 сек - ок. А 0.5 сек? А 1 сек?
Опять же, в контексте чего мы говорим: одно дело ночная регламентная процедура, и совсем другое когда пользователь жмет кнопку добавить в таб.части.

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

(66) Котик не вариант, прогресс должен быть информативным, дающим возможность оценить время, на которое пользователь может отвлечься)

(79) на экзамене проверяют твое умение писть запросы не только в цикле

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

(84) А бывает и наоборот.

(80) даже при интерактивном действии пользователь не заметит потерь в доли секунды
(83) про "только в цикле" никто и не говорит. Скажем так, запрос в цикле иногда допустим, а маниакальное избавление от запросов в цикле приводит к неимоверному усложнению кода.
(84) это уже вопрос прогнозирования объема данных и тестирования производительности

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

(79) "Всегда должен быть баланс между "легкостью" и производительностью кода"+100500. Все зависит от ситуации. А то иногда месяц ваяют запрос без цикла, который собственно раз в году понадобится и сэкономит пользователю пару минут. по итогу затраты на разработку окупаются спустя десять лет экплуатации системы)

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

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

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

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

(89) а потом когда в этот мега запрос нужно поле добавить - плюешься на разрабов типовых

(92) схема запросов рулит. я тут для себя открыл ее прелесть. Офигенный запрос собирается по 100500 процедурам в 100500 модулям. мучался мучался, потом перед передачей запроса в текст запроса прописал передачу в схему запроса, добавил нужное поле и обработанный текст отдал запросу. песТня!