Вход | Регистрация
 

Запрос в цикле

Запрос в цикле
Я
   craxx
 
29.04.19 - 12:23
Набившая оскомину тема. Запрос в цикле. Когда он выгоднее, чем запрос вне цикла?
У меня на ум приходит только соединение двух больших таблиц, когда много соединений маленьких выполнится быстрее большого соединения.
У кого какие еще примеры?
 
 
   azernot
 
1 - 29.04.19 - 12:26
>Запрос в цикле. Когда он выгоднее, чем запрос вне цикла?

Правильный ответ - никогда.
Если факт противоречит этому,  это говорит о том, что неверно организован запрос вне цикла.
   xXeNoNx
 
2 - 29.04.19 - 12:27
(0) в комплексе с другими моментами когда количество итераций цикла известна заранее и решение того стоит
   craxx
 
3 - 29.04.19 - 12:28
(1) неправильный ответ. в моем случае выгоднее именно в цикле. ибо сумма квадратов всегда меньше квадрата суммы
   xXeNoNx
 
4 - 29.04.19 - 12:28
(1) >> Правильный ответ - никогда.
А обоснования данного тезиса у Вас есть?
   ptiz
 
5 - 29.04.19 - 12:30
(0) Например, запрос вызывается с такими разными наборами параметров, для которых неэффективно получать всё в одном запросе.
   xXeNoNx
 
6 - 29.04.19 - 12:30
+(4) (1) Вы просто не умеете их готовить (с)ВР
   azernot
 
7 - 29.04.19 - 12:35
(3) Не понимаю причём тут это.
(4) Конечно. Как минимум не тратится время на иннициацию запроса, передачу параметров и т.п.

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

Т.е. если я устрою цикл из 4-х элементов (УУ, БУ, НУ, МУ) и далее отдельно формирую запросы к разным данным, я не считаю это "запросом в цикле".
   xXeNoNx
 
8 - 29.04.19 - 12:42
(7) >> я не считаю это "запросом в цикле"
о как.., тут - это запрос в цикле, там нет
Еще один пример: получение различных начислений по сотруднику так же не не запрос в цикле?
   exwill
 
9 - 29.04.19 - 12:43
(0) Запрос в цикле практически всегда лучше, чем решение той же задачи через запрос вне цикла.
1. Лучше использовать явный цикл, чем неявный. Это понятнее и нагляднее.
2. Оптимизировать надо там, где есть потребность в оптимизации.
3. Незачем потакать лени разработчиков платформы. В чем проблема выносить запросы из циклов на уровне платформы? Разве не этим она должна заниматься?
   H A D G E H O G s
 
10 - 29.04.19 - 12:44
(0) Когда есть составное поле и ты не знаешь все его типы до выполнения запроса.
   craxx
 
11 - 29.04.19 - 12:44
(10) Плюсану. Только что об это подумал
   H A D G E H O G s
 
12 - 29.04.19 - 12:49
(9) вам лучше продолжать писать в политике.
   azernot
 
13 - 29.04.19 - 12:54
(8) Хорошо скажем так, я под "запросом в цикле" подразумеваю один и тот же запрос (или с очень минимальными правками) в который передаются разные параметры, перебираемые в цикле. Т.е. цель цикла - именно в переборе параметров.

В остальных случаях, когда цикл нужен просто для более удобной и универсальной компоновки текста запроса, перебора источников и т.п. я не считаю это "запросом в цикле", это просто метод программирования. И тут ответ на вопрос в (0) зависит от очень многих факторов, что на него просто невозможно ответить "вообще и в целом".
   xXeNoNx
 
14 - 29.04.19 - 13:03
(13) так точно -> (2) + (6)
Но однозначно сказать что запрос в цикле это плохо - нельзя!
   craxx
 
15 - 29.04.19 - 18:38
(14) У большинства другое мнение)
   polosov
 
16 - 29.04.19 - 20:25
(0) Он выгоднее тогда, когда надо решить задачу, но ты не знаешь как сделать без него.
(10) Надо строить запрос кодом.
(9) Я надеюсь это ты тралишь, а не выражаешь свое профессиональное мнение.
Однозначно, выборка  данных единым запросом лучше, чем дергание СУБД постоянными запросами поменьше, ибо возрастает вероятность блокировок.
   H A D G E H O G s
 
17 - 29.04.19 - 20:27
(16) В смысле - запрос - кодом?
   H A D G E H O G s
 
18 - 29.04.19 - 20:29
Я вот про это:

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

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

и постобработкой получить номера, с числом запросов= количеству различных типов регистратора.
   polosov
 
19 - 29.04.19 - 20:29
(17) Всмысле в зависимости от входных данных (например, анализа метаданных) строишь тело запроса. Что-то мне не верится, что для тебя такое в новинку
   polosov
 
20 - 29.04.19 - 20:32
(18) В зависимости от типов своих регистраторов делаешь
Выбрать ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.ТВОЙ_ТИП_ДОКУМЕНТА).Номер как НомерДокумента 
из РегистрНакоплений.Продажи как Продажи
Где Продажи.Период>&НачалоМесяца
ОБЪЕДИНИТЬ ВСЕ 
и тд и тп
   H A D G E H O G s
 
21 - 29.04.19 - 20:42
(20) Откуда ты узнаешь, какие типы регистраторов попали в выборку ДО выполнения запроса?
   H A D G E H O G s
 
22 - 29.04.19 - 20:44
Выбрать ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.ТВОЙ_ТИП_ДОКУМЕНТА).Номер как НомерДокумента 
из РегистрНакоплений.Продажи как Продажи
Где Продажи.Период>&НачалоМесяца
ОБЪЕДИНИТЬ ВСЕ 

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


ВЫБОР КОГДА Продажи.Регистратор ССЫЛКА Документ.ТВОЙ_ТИП_ДОКУМЕНТА1 ТОГДА
ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.ТВОЙ_ТИП_ДОКУМЕНТА1).Номер
КОГДА Продажи.Регистратор ССЫЛКА Документ.ТВОЙ_ТИП_ДОКУМЕНТА2 ТОГДА
ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.ТВОЙ_ТИП_ДОКУМЕНТА2).Номер
   polosov
 
23 - 29.04.19 - 20:54
(21) Хорошо. Если у тебя такая задача, то держи.
1. Кодом получаешь типы регистраторов.
2. Строишь запрос.
(22) Да, можно и так.
   H A D G E H O G s
 
24 - 29.04.19 - 20:57
(23) Каким кодом?
   H A D G E H O G s
 
25 - 29.04.19 - 20:58
(23) "Да, можно и так."

Весело там у вас.
   polosov
 
26 - 29.04.19 - 20:58
(24) запрос для поисковой машины: "Как получить типы регистраторов в регистре накопления"
   polosov
 
27 - 29.04.19 - 21:01
(25) Вот тут не совсем понимаю. Хочешь сказать, что case сильно оптимальнее union?
   H A D G E H O G s
 
28 - 29.04.19 - 21:02
(26) Ты прикалываешься?
Еще раз вчитайся внимательно во фразу
"Откуда ты узнаешь, какие типы регистраторов попали в выборку ДО выполнения запроса?"
   polosov
 
29 - 29.04.19 - 21:03
(28) ХЗ, может ты прикалываешься? У тебя нет доступа к РН до выполнения запроса?
   H A D G E H O G s
 
30 - 29.04.19 - 21:03
(27) union потребует x поисков по таблице, где x - количество типов регистраторов с последующим merge
 
 
   polosov
 
31 - 29.04.19 - 21:05
(30) Ты вроде с планами дружишь. Можешь быстренько глянуть? Я просто, утверждать не берусь, но подглядел такие union на взрослых системах еще во времена обучения.
   H A D G E H O G s
 
32 - 29.04.19 - 21:05
(29)
с 1 января по 31 января были только ПТУ.
1 февраля были только РТУ.
У нас выборка с 2 февраля.
Вопрос - надо ли трогать таблицу ПТУ?
   polosov
 
33 - 29.04.19 - 21:07
(32) А что-то изменится, если в union all попадет выборка из РН по типу регистратора, которого нет за это период?
   H A D G E H O G s
 
34 - 29.04.19 - 21:08
Вот жесть жеж.
   polosov
 
35 - 29.04.19 - 21:10
(34) Не ну тебе виднее, ты же собак много съел на запросах.
   polosov
 
36 - 29.04.19 - 21:12
(34) Мне просто нравится твоя жесть. Вытащить регистраторы запросом, а потом из выборки вытащить типы регистраторов, а потом построить запросы.
   H A D G E H O G s
 
37 - 29.04.19 - 21:15
(36) Рекомендую собрать план запроса в какой-нибудь ERP для

ВЫБРАТЬ ПЕРВЫЕ 10
    ДвиженияСерийТоваров.Регистратор.Номер КАК РегистраторНомер
ИЗ
    РегистрНакопления.ДвиженияСерийТоваров КАК ДвиженияСерийТоваров
   DomovoiAtakue
 
38 - 29.04.19 - 21:25
(0)Когда есть уже готовые запросы и их вызовы не создают видимые тормоза. Лучше использовать уже готовые запросы как например ПолучитьЦену() чем каждый раз клепать что-то свое. Все пишут запросы в цикле, странно, что кто-то еще говорит: "Запросы в цикле - зло".
   Garykom
 
39 - 29.04.19 - 21:31
(38) Странно это не понимать и не стараться избегать всеми силами.
Там только на передаче данных туда-сюда между сервером 1С и sql сервером куча накладных расходов.
   H A D G E H O G s
 
40 - 29.04.19 - 21:37
   H A D G E H O G s
 
41 - 29.04.19 - 21:37
   H A D G E H O G s
 
42 - 29.04.19 - 21:38
Критикуешь - предлагай?!
Несомненно:
https://youtu.be/fEYceCWI_h0
   polosov
 
43 - 29.04.19 - 21:42
(37) У тебя вроде маркировка больная тема, отсюда и отсылки к своим любимым сериям. Но я человек простой, запросы строю за деньги.
(40) , (41) , (42)  Ты уже принял писят грамм "чтобы спалось лучше"? ))
   polosov
 
44 - 29.04.19 - 21:43
(37) И да, традиционно: опиши задачу, возможно ты решаешь ее не правильно.
   Garykom
 
45 - 29.04.19 - 21:45
(36) >Вытащить регистраторы запросом, а потом из выборки вытащить типы регистраторов, а потом построить запросы.
(43) >У тебя вроде маркировка больная тема, отсюда и отсылки к своим любимым сериям. Но я человек простой, запросы строю за деньги.

Типовые конфы, метаданные сильно не исправишь, приходится выкручиваться чем можно.
Ибо работать то надо на то что есть.
   H A D G E H O G s
 
46 - 29.04.19 - 21:46
(45) Можно денормализовать, но устроила постобработка.
   Garykom
 
47 - 29.04.19 - 21:47
(46) Блин напомнил про хитрый хак.
Когда вместо исправления головоломного запроса на несколько экранов.

Тупо и банально после него подсовываем (в т.ч. кодом) что надо для отчета.
   Garykom
 
48 - 29.04.19 - 21:48
(47)+ В результат после выполнить подсоваем
   Garykom
 
49 - 29.04.19 - 21:48
(48) тьфу *подсовываем или изменяем данные как надо.
   polosov
 
50 - 29.04.19 - 21:51
(47) Да все мы, бывает, говнокодим.
   H A D G E H O G s
 
51 - 29.04.19 - 21:58
(50) нет.
   DomovoiAtakue
 
52 - 29.04.19 - 21:59
(39)Избегать запросов в цикле?
   polosov
 
53 - 29.04.19 - 22:01
(51) Ой не смеши.
   exwill
 
54 - 29.04.19 - 22:59
(16) Я вроде бы достаточно ясно выразился.
Простота кода важнее производительности, которую, в идеале, должна обеспечивать платформа.
   palsergeich
 
55 - 29.04.19 - 23:09
Пример, ранее обсосанный на форуме:
Получить всех родителей элемента в иерархическом справочнике, если глубина иерархии неизвестна, и считается что может быть большой (больше 10).
   craxx
 
56 - 30.04.19 - 05:35
(54) ты это пользователям потом расскажешь, которые спросят за тормоза
   craxx
 
57 - 30.04.19 - 05:36
(55) пример не совсем корректный ибо он изначально запросом не решается
   Лодырь
 
58 - 30.04.19 - 05:54
   craxx
 
59 - 30.04.19 - 05:56
(58) Я знаю эту тему, пробовал собирать запросом, по скорости полный трэш, собрал программно в 20 раз быстрее.
   Лодырь
 
60 - 30.04.19 - 06:05
(59) Ну так palsergeich и написал что быстрее ) Но ведь можно же.
   seevkik
 
61 - 30.04.19 - 06:36
В чем заключается выгода?)

Как-то надо было добавить поле со значением дополнительного реквизита, подумав "надо сделать все шикарно", я менял запрос в документе (не самый сложный, но далеко не простой), делов на 10 минут, как раз расширения стали популярны - добавил в расширение, поменял все в запросе, получил допреквизит, вроде по феншую.
Периодически, при обновлении, этот участок кода менялся, иногда запрос, иногда код, доработка совсем мелкая, малозначимая, каждый раз мне приходилось заново в нее вникать, частенько я про нее забывал - тогда приходили тикеты, они отнимали мое время, мешали зависать на формуах тыжпрограммистов, смотреть на котиков в тырнетах, тратили силы и нервы. Я не мог больше работать. Я был в депрессии. Однажды мне это надоело. В цикле этого запроса воткнув "УправлениеСвойствами.ЗначениеСвойства" я получил большую выгоду в виде времени, с тех пор жизнь начала налаживаться, трава стала зеленее, солнце ярче, и я понял что запросы в цикле это не плохо
   Провинциальный 1сник
 
62 - 30.04.19 - 06:40
Когда делаешь запрос в цикле - ты можешь легко оценить оставшееся до завершения алгоритма время. В случае же, если мегазапрос выполняется sql-сервером, ты не видишь никакого прогресса, программа тупо "висит". Для пользователя приятнее видеть прогресс-бар минуту, чем полминуты зависшее окно.
   Simod
 
63 - 30.04.19 - 07:30
(0) Когда необходимо ограничить размер выборки и обрабатывать по частям:

<CODE>
ВЫБРАТЬ ПЕРВЫЕ 1000
...
</CODE>
   Prog111
 
64 - 30.04.19 - 07:59
Выгоднее в случаях:

1) Алгоритм будет использоваться редко (какая-нибудь разовая обработка, отчет, запускающийся раз в полгода).
2) Количество циклов предсказуемо и небольшое (например, количество районов в городе 4-5) и не влияет особо на скорость исполнения алгоритма.
3) Разработка более сложного кода (без циклов) будет более затратна, чем эффект от экономии использования более оптимального кода.
   Dotoshin
 
65 - 30.04.19 - 08:17
(0) Есть ситуации, когда запрос в цикле не выгоднее, а единственно возможное решение. Например разузлование спецификации номенклатуры или построение дерева затрат без СКД.
Может я конечно чего-то не знаю, поэтому если есть способ без цикла и без СКД, то прошу поделиться.
   H A D G E H O G s
 
66 - 30.04.19 - 10:13
(62) включи ему gif-ку
 
 Рекламное место пустует
   Успехов
 
67 - 30.04.19 - 10:15
(65) Когда ты знаешь максимальную глубину вложенности можно и без запроса в цикле.
   kolts23381
 
68 - 30.04.19 - 10:26
А что насчет запросов в цикле из временных таблиц?
   Конструктор1С
 
69 - 30.04.19 - 10:28
Запрос в цикле допустим, если он:
а) не губит производительность
б) делает код проще и удобочитаемее, по сравнению с запросом "по феншую"
   Вафель
 
70 - 30.04.19 - 10:28
(65) скд теже циклы крутил. или раз я не пишу слово цикл - значит я молодец?
   Sammo
 
71 - 30.04.19 - 10:33
Была ситуация (правда еще на 8.1 и 8.2) когда выборка более 1млн записей падала. А поскольку требовалось сформировать данные за месяц (порядка 20млн записей), то приходилось разбивать месяц по периодам и формировать кусками.
   stix2010
 
72 - 30.04.19 - 10:55
а давате похоливарим на тему запросы в цикле от разработчиков типовых?
   Nikoss
 
73 - 30.04.19 - 11:14
(69) если (а) никогда не выполняется, смысл писать про (б)?
   Nikoss
 
74 - 30.04.19 - 11:18
(71) зачем нужна выборка на 1млн (или темболее 20млн) записей? Что с ними делать?
   Конструктор1С
 
75 - 30.04.19 - 11:33
(73) в каком смысле не выполняется? У производительности тоже есть границы разумного. Допустим, в справочнике заведомо 100 элементов, за раз нужно получить 5 элементов. Тут совершенно пофиг, как ты там будешь получать эти данные из справочника, хоть через точку, хоть запросами в цикле, хоть "оптимальным" запросом, ибо всё оно будет выполняться моментально. Ну перепишешь ты запрос оптимально, выиграешь 0,00003 секунды, а пользователь этого никогда не заметит. Что это даст?
В то же время попытки получить данные одним большим запросом заведомо усложняют решение.
   Вафель
 
76 - 30.04.19 - 11:36
если данных слишком много, то за запрос без цикла ручки то нужно вырывать
   Nikoss
 
77 - 30.04.19 - 11:41
(75) ок, тогда пункт (а) из (69) нужно разворачивать - "..., в границах разумного". Только у каждого свое понимание разумного. Какое понимание, допустим, у экзаменаторов 1С?
   Nikoss
 
78 - 30.04.19 - 11:42
(76) ты мне про (74)?
   Конструктор1С
 
79 - 30.04.19 - 11:55
(77) у экзаменаторов 1С какие-то свои представления о производительности. "Вот вам база из двух справочников по три элемента в каждом, пишите оптимальные запросы"
пункт (а) из (69) разворачивать не нужно. Затраты в лишние 0,005 секунд на всю операцию субъективно никак не влияют на производительность. Такого "ухудшения производительности" никто и никогда не заметит. В то же самое время, не рентабельно тратить часы на оптимизацию и делать код менее читабельным, ради сомнительного выигрыша в 0,005 секунд. Всегда должен быть баланс между "легкостью" и производительностью кода
   Nikoss
 
80 - 30.04.19 - 12:14
(79) 0.005 сек - ок. А 0.5 сек? А 1 сек?
Опять же, в контексте чего мы говорим: одно дело ночная регламентная процедура, и совсем другое когда пользователь жмет кнопку добавить в таб.части.
   stix2010
 
81 - 30.04.19 - 12:22
(79) мне кажется это самое логичное, если производительность не критична, то выигрывает скорость разработки.
   Провинциальный 1сник
 
82 - 30.04.19 - 12:23
(66) Котик не вариант, прогресс должен быть информативным, дающим возможность оценить время, на которое пользователь может отвлечься)
   Вафель
 
83 - 30.04.19 - 12:42
(79) на экзамене проверяют твое умение писть запросы не только в цикле
   Nikoss
 
84 - 30.04.19 - 12:47
(81) скорость разработки и производительность - палка о двух концах. На момент разработки, процедура с запросом в цикле может выполняться мгновенно, а после, условного, года наполнения таблиц данными - вечность.
   Провинциальный 1сник
 
85 - 30.04.19 - 12:48
(84) А бывает и наоборот.
   Конструктор1С
 
86 - 30.04.19 - 13:04
(80) даже при интерактивном действии пользователь не заметит потерь в доли секунды
(83) про "только в цикле" никто и не говорит. Скажем так, запрос в цикле иногда допустим, а маниакальное избавление от запросов в цикле приводит к неимоверному усложнению кода.
(84) это уже вопрос прогнозирования объема данных и тестирования производительности
   oslokot
 
87 - 30.04.19 - 13:12
(62) один хрен форма зафризится, будь то запрос в цикле или один мега-запрос
Все равно надо выполнять в фоне, а пользователю - кота
   Ник080808
 
88 - 30.04.19 - 13:59
(79) "Всегда должен быть баланс между "легкостью" и производительностью кода"+100500. Все зависит от ситуации. А то иногда месяц ваяют запрос без цикла, который собственно раз в году понадобится и сэкономит пользователю пару минут. по итогу затраты на разработку окупаются спустя десять лет экплуатации системы)
   Dotoshin
 
89 - 30.04.19 - 14:34
(88) Когда разрабатывается тиражной решение, то не известно сколько раз в году будет выполняться запрос и сколько пользователей одновременно будут его выполнять и сколько пользователей и как долго будут пытаться заблокировать таблицы, которые читает запрос тоже неизвестно. Вот поэтому и требуют писать оптимально и без циклов.
А когда делаешь отчетик для тети Мани, которая раз в год его запустит, то можешь хоть в цикле, хоть через три точки к данным обращаться...
   Ник080808
 
90 - 30.04.19 - 15:47
(89) так о том и речь, что многие воспринимают как догму рекомендации. мы пишем бизнес приложение и нужно оценивать задачу с точки зрения выгоды бизнеса. Тиражные решения пишут единицы, основная масса допиливает типовые или нетленки под конкретное предприятие. Поэтому нужно понимать, что дешевле - полдня работы 1снега или пять минут работы оператора ПК и от этого и отталкиваться - стоит заморачиваться с запросом или стоит наговнокодить.
   Сияющий в темноте
 
91 - 30.04.19 - 17:07
Начнем с того,что 1с не умеет prepare  execute,что позволякт без.проблем гонять запросы в цикле.
без этой особенности,мы получаем,что на каждый запрос выполняется построение плана,а это трата времени и лишняя нагрузка на сервер.

однако,например,во всех конфигурациях,где есть регист ЦеныНоменклатуры,есть функция ПолучитьЦену,которая вызывается в цикле по таблице товароа,а это и есть запрос в цикле
   Вафель
 
92 - 30.04.19 - 17:11
(89) а потом когда в этот мега запрос нужно поле добавить - плюешься на разрабов типовых
   Ник080808
 
93 - 30.04.19 - 19:45
(92) схема запросов рулит. я тут для себя открыл ее прелесть. Офигенный запрос собирается по 100500 процедурам в 100500 модулям. мучался мучался, потом перед передачей запроса в текст запроса прописал передачу в схему запроса, добавил нужное поле и обработанный текст отдал запросу. песТня!


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.