Нарастающие итоги в запросе и методы ускорения его выполнения.

Опубликовал anig99 в раздел Программирование - Практика программирования

В статье рассматривается метод получения нарастающих итогов в запросе и методы ускорения его выполнения для больших объемов данных.


Любезные критики, смотрите P.S. к статье.
Есть множество задач, в которых требуется получение и/или обработка нарастающих итогов. В частности это дебиторская/кредиторская задолженность и расчетные листки. Задача легко решается в рамках встроенного языка, но по разным причинам это не всегда приемлемо (подробнее см. P.S.).  Язык запросов 1с позволяет получить нарастающие итоги. Как подсказывает логика, итоги должны нарастать относительно какого-либо показателя. Самый распространенный случай – период. Именно такой случай и будет рассматривать. Так как лично столкнулся с необходимостью использования нарастающих итогов в рамках анализа дебиторской задолженности, то и в статье будем рассматривать её.
Итак, для чего при анализе дебиторской задолженности могут потребоваться нарастающие итоги? Для формирования списка документов по текущей задолженности (при этом абсолютно не важно с какой степенью детализации ведутся взаиморасчеты – алгоритм такой же). Этот список даёт важную информацию для дальнейшего анализа – дата возникновения задолженности, число дней долга, если есть параметр числа дней задолженности, то количество дней просрочки, сумма просроченного долга, ну и сам список документов долга.
Для начала нам потребуется получить список документов взаиморасчетов контрагента:
Реализация товаров и услуг №1          500р
Реализация товаров и услуг №2          1000р
Платежное поручение исходящее №1 -500р
Реализация товаров и услуг №3          1200р
Итого                                                  2200р

Для того чтобы получить нарастающий итог нужно использовать ещё одну такую же таблицу и связать её с первой. Связывать нужно по дате (при совпадении времени можно дополнительно сравнивать по моменту времени), но связывать не через равенство, а через сравнение >= или
Реализация товаров и услуг №1           500р 500р
Реализация товаров и услуг №1           500р 1000р
Реализация товаров и услуг №1           500р -500р
Реализация товаров и услуг №1           500р 1200р
Реализация товаров и услуг №2           1000р 1000р
Реализация товаров и услуг №2           1000р -500р
Реализация товаров и услуг №2           1000р 1200р
Платежное поручение исходящее №1 -500р -500р
Платежное поручение исходящее №1 -500р 1200р
Реализация товаров и услуг №3           1200р 1200р


Как-то некрасиво…А, ну да! Нужно сгруппировать по всем поля Основного списка с суммированием поля вспомогательного. В итоге получим искомое:

Реализация товаров и услуг №1           500р 2200р
Реализация товаров и услуг №2           1000р 1700р
Платежное поручение исходящее №1  -500р 700р
Реализация товаров и услуг №3           1200р 1200р


Пример запроса

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

СГРУППИРОВАТЬ ПО
    ПериодыИзменения.Период


Все…..можно было бы и так сказать, но у такого решения есть один существенный недостаток – с ростом числа строк в таблице время выполнения запроса увеличивается геометрически (или экспоненциально). Для ускорения требуется оптимизация. Приведу 3 способа:
1. Ограничить период в запросе. Самый распространенный (честно говоря единственный найденный мной на степях интернета), позволяет ограничить число строк в таблице, а значит и ускорить время запроса. Наиболее легкий способ, но имеет недостаток – всё что не входит в период не суммируется – можно и не угадать с периодом, да и необходимее периоды иногда бывают очень большими.

2. Метод последовательного приближения. Строго говоря, метод не ускоряет получения нарастающих итогов для всей таблицы, а только ускоряет поиск нужного значения с использованием нарастающих итогов. Вернемся к примеру с дебиторской задолженностью. Таблица документов долга не будет совпадать со всей таблицей – 500 рублей уже заплатили. Нам требуется получить таблицу с документами возникновения долга (реализация) сумма которых в обратном порядке от последнего числа равна текущему долгу 2200р. Для таких малых таблиц ускорение не требуется, но когда речь идет о большом количестве контрагентов и взаиморасчетах за несколько лет, то можно применить метод последовательного приближения. Идея заключается в том, чтобы сгруппировать документы по периоду и детализировать только нужные периоды. Удобнее всего это делать через пакетные запросы. В моем случае я использовал следующий алгоритм: сначала получил 3 дополнительные таблицы: группировка по годам, группировка по месяцам и группировка по дням. Сначала уже известным способом для таблицы по годам рассчитываем нарастающие итоги. Далее получаем из неё 2 таблицы: если сумма долга с нарастанием для года меньше общего долга, то включаем его в таблицу безусловного включения в конечную таблицу, а первый год, где итоговая сумма больше долга (год с минимальным превышением), отправляем в таблицу для дальнейшего рассмотрения и не забываем передать туда сумму остатка долга (общая сумма долга минус сумма долга из таблицы безусловного включения). Именно по этой таблице отбираем данные из таблицы сгруппированной по месяцам. И также как для таблицы с годами, делим её на 2 таблицы по сумме остаточного долга. Далее таблицу для дальнейшего рассмотрения используем для отбора в таблице по дням. Ну и после делаем всё тоже самое для дальнейшего рассмотрения по дням и основной таблицы.. В результате мы получаем следующие таблицы: безусловное включение по годам, безусловное включение по месяцам, безусловное включение по дням и документы долга в первый день (наиболее удаленные от дня отчета) долга. В последней фазе отбираем из основной таблицы конкретные документы с использованием вышеперечисленных таблиц. Объединяем и вуаля! Готовая таблица документов долга.
Недостаток этого метода – сложность реализации. Сама реализация на http://infostart.ru/public/20221/ - ссылка на файл "Новый запрос"

3. Метод сложения периодов. Более универсальный метод и позволяет ускорить именно получение нарастающих итогов. При расчете нарастающих итогов в условие связи добавляется дополнительное условие, чтобы разделить общую таблицу на подтаблицы (желательно помельче). Далее последовательно объединяем эти подтаблицы в более крупные подтаблицы с нарастанием итогов - к каждому последующему периоду прибавляется итоги (последняя сумма в подтаблице) предыдущих периодов. И так далее в зависимости от выбранного для конкретного случая числа итераций.
Недостаток метода – тоже достаточная сложность реализации и то, что этот метод не разработан в деталях – я окончательно его сформулировал только что.

P.S. «Не надо ругать пианиста, он играет как умеет». Я работаю с 8кой, поэтому не могу сказать, что частности реализации методов для 7ки будет таким же (если это вообще возможно), но общие алгоритмы универсальны.

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

Метод подсчета нарастающих итогов известен и много раз публиковался на форумах, но именно подробной статьи не было. Метод простой, и статья только про него вышла бы очень короткой. Поэтому добавил описание методов ускорения расчетов. 1 метод используют для ускорения расчетов только запросом (если ускорение вообще используется) все отчеты по задолженности, которые я рассматривал. И в некоторых комментариях я уже писал, что ограничение глубины рассмотрения задолженности – это метод Александра Македонского для узлов – проблема вроде бы решена, только веревка уже не целая. 2 метод я использую для своих отчетов по дебиторской задолженности. После применения этого метода время исполнения отчета для достаточно крупной базы (по всем покупателям) уменьшилось с более 30 минут, до минуты и менее – и не надо про производительность и т.д. всё это уже проверялось. Все варианты отчетов можно посмотреть в моих разработках, в т.ч. и запрос по методу 2 в чистом виде. Ну и 3 метод мне пока не требовался и окончательно я его сформулировал только сейчас. Дискуссия и плюсование поощряется.

См. также

Лучшие комментарии

10. anig99 19.10.2009 19:09
(9) я не пишу статьи для развлечения и самоцелей. В 1с есть замечательные механизмы по быстрому формированию отчетов: всевозможные консоли отчетов, создание отчета как внешней обработки и создание внешнего отчета. И если есть возможность решить задачу только средствами запроса, то сделать отчет можно без лишних усилий и лишнего кода. Кроме того, есть ещё два плюса, в которых я не уверен, так ли это - запрос выполняется на сервере, а значит на предположительно более мощной машине - отчет по дебиторке с запросом на небольших объемах данных выполняется быстрее отчета на встроенном языке. А на больших объемах данных быстрее оптимизированный вариант. Второй фактор - работа с web-клиентами (тут я только предполагать могу, т.к. слышал что-то краем уха, поэтому не буду утверждать)
Ответили: (11)
+ 2 [ artbear; larisab; ]
# Ответить
14. anig99 19.10.2009 22:13
(12) он предлагает пройтись по таблице значений и последовательно наращивать итоги...
и мода-не мода, но индексированность данных не самый последний фактор в скорости расчетов.
+ 1 [ larisab; ]
# Ответить
17. anig99 19.10.2009 23:16
(15) ускорение относительно именно варианта с программным решением. Между прочим, 3 оператора, подойдут только если нам нужен итог... а если брать не одного контрагента, да ещё и не только в одном разрезе... Пример в статье для самого простого случая. Реальные задачи часто много сложнее. Я не утверждаю, что программный способ плох. Я говорю, что есть задачи, где он менее эффективен и удобен, чем запросный метод.
Ответили: (19)
+ 1 [ larisab; ]
# Ответить
19. hogik 20.10.2009 00:10
(17)
"3 оператора, подойдут только если нам нужен итог"
"Пример в статье для самого простого случая."
Ну и мой пример для этого самого случая. ;-)
"говорю, что есть задачи, где он менее эффективен и удобен, чем запросный метод."
Именно - так. Но мы то говорим о конкретной задаче, где запросный метод НЕ эффективен и НЕ удобен. И Ваша статья, на мой взгляд, это подтверждает.

Спасибо за интересную беседу. Желаю успехов.
Ответили: (20)
+ 1 [ anig99; ]
# Ответить
65. Александр Медведев 22.11.2009 11:44
(62) Гы-гы...Думал когда же всплывет (: Для того, чтобы отсортировать документы с одинаковой датой сравниваю ещё по ссылке <=. Ведь что есть Момент времени? Виртуальный тип, который содержит в себе Дату и ссылку.
(63) Итоги то с нарастающим, но там все итоги, а нам нужны только по документам увеличивающим задолженность
С разными виртуальными таблицами есть ещё лажа с Границами, в таблице остатки нельзя задать условие не границу, её туда надо в виде параметра запихивать, а в ОстаткахИОборотах есть соответствующий параметр, который преобразовывает дату в границу. Вот тут и есть глобальная подстава для СКД... Штатным конструктором нельзя границу в запрос СКД передать, только с помощью кода. Поэтому когда быстро ваяешь запрос по виртуальной таблице Остатки в СКД, нужно помнить, что граничные значения не получишь.
Ответили: (66)
+ 1 [ jk3; ]
# Ответить

Комментарии

1. PowerBoy 19.10.2009 07:17
А код где? Непонятно так.
Ответили: (34) (2)
# Ответить
2. anig99 19.10.2009 07:31
(1) готовый код конечно могу выложить, если непонятно. По мне, так лучше алгоритм раскрыть, чем тупо выложить код, в котором нужно разбираться. В течении дня код дополню.
# Ответить
3. anig99 19.10.2009 08:04
Буратино был тупой...тупой как дрова (:
Зыбыл как статью пометить. Исправился
# Ответить
4. Трактор 19.10.2009 10:17
Нужен пример запроса. Однозначно. Запрос, чувствуется, будет довольно сложным.

"Видала я котов без улыбок, но вот улыбку без кота ещё ни разу" (с) Алиса
Теперь по-русски.
Я видал много программ без описаний, но вот описание без программы встретишь не часть.
Ответили: (7) (5)
# Ответить
5. anig99 19.10.2009 10:24
(4) ща прямую ссылку кину.
# Ответить
6. anig99 19.10.2009 10:27
Сама реализация на http://infostart.ru/public/20221/ - ссылка на файл "Новый запрос"
# Ответить
7. anig99 19.10.2009 10:38
(4) и вроде бы это уже с утра статья
Ответили: (8)
# Ответить
8. Трактор 19.10.2009 10:40
(7) не важно статья это или программа. Важно что есть описание к коду, а кода нет. Теперь есть ссылка на код и то хорошо.
# Ответить
9. hogik 19.10.2009 18:07
(0)
Данная задача (по самой сути алгоритма) решается легко и эффективно без запросов. Решать данную задачу запросом - это самоцель? Или в "1С 8.х" другого способа решения данной задачи не существует?
Ответили: (11) (10)
# Ответить
10. anig99 19.10.2009 19:09
(9) я не пишу статьи для развлечения и самоцелей. В 1с есть замечательные механизмы по быстрому формированию отчетов: всевозможные консоли отчетов, создание отчета как внешней обработки и создание внешнего отчета. И если есть возможность решить задачу только средствами запроса, то сделать отчет можно без лишних усилий и лишнего кода. Кроме того, есть ещё два плюса, в которых я не уверен, так ли это - запрос выполняется на сервере, а значит на предположительно более мощной машине - отчет по дебиторке с запросом на небольших объемах данных выполняется быстрее отчета на встроенном языке. А на больших объемах данных быстрее оптимизированный вариант. Второй фактор - работа с web-клиентами (тут я только предполагать могу, т.к. слышал что-то краем уха, поэтому не буду утверждать)
Ответили: (11)
+ 2 [ artbear; larisab; ]
# Ответить
11. hogik 19.10.2009 19:45
(10)
Видимо в (9) я плохо изложил свою мысль. Попробую сказать иначе - данную задачу надо решать без применения запроса...
Ответили: (13) (12)
# Ответить
12. Шёпот теней 19.10.2009 22:06
всегда ЕСТЬ мода... нынче ВСЕ увлеклись Запросами ... ХМЛ-ями ...

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


... (11) ... так КАК же данную задачу надо решать ...? товарищь hogik..?

... вотРасскажите ...
Ответили: (16) (14)
# Ответить
13. anig99 19.10.2009 22:10
(11) видимо плохо объяснил свою... Данную задачу МОЖНО решить без применения запроса и это наиболее привычный для многих способ. Но наиболее привычный - это не во всех случаях наиболее простой или наиболее оптимальный. Ещё раз - применение алгоритмов из статьи существенно ускорило выполнения отчета на больших объемах данных.
Вопрос регулярно подымается на различных форумах. Иногда очень неудобно увеличивать срок разработки отчета из-за необходимости писать код для программной обработки данных и их вывода.
Кроме того, методы последовательного приближения вполне применим и для программного исполнения.
Ответили: (15)
# Ответить
14. anig99 19.10.2009 22:13
(12) он предлагает пройтись по таблице значений и последовательно наращивать итоги...
и мода-не мода, но индексированность данных не самый последний фактор в скорости расчетов.
+ 1 [ larisab; ]
# Ответить
15. hogik 19.10.2009 23:03
(13)
"применение алгоритмов из статьи существенно ускорило"
Возможно и ускорило по сравнению с алгоритмом от которого начинаются Ваши рассуждения. Только, думаю, еще больше будет ускорение, если (упрощенно говоря(!) - на Вашем примере) "взять список документов взаиморасчетов контрагента" и просмотреть его в обычном цикле из трех операторов с подсчетом нарастающего итога. При этом "взять список документов" можно и запросом, а можно и внутри этого же цикла получать поштучно.
Ответили: (17) (16)
# Ответить
16. hogik 19.10.2009 23:04
(12)
" так КАК же данную задачу надо решать ...? товарищь hogik..?"
Уважаемый Александр ("Шёпот теней"), я Вам не товарищ. А если это "партийное" обращение, то тем более не к месту. Т.к. будучи рожденным в 1955 году, я даже в комсомоле не состоял... ;-)
А решение описано в предыдущем (15) сообщении данной темы.
+ 1 [ artbear; ]
− 1 [ Spacer; ]
# Ответить
17. anig99 19.10.2009 23:16
(15) ускорение относительно именно варианта с программным решением. Между прочим, 3 оператора, подойдут только если нам нужен итог... а если брать не одного контрагента, да ещё и не только в одном разрезе... Пример в статье для самого простого случая. Реальные задачи часто много сложнее. Я не утверждаю, что программный способ плох. Я говорю, что есть задачи, где он менее эффективен и удобен, чем запросный метод.
Ответили: (19)
+ 1 [ larisab; ]
# Ответить
18. Шёпот теней 19.10.2009 23:43
... раньше форма и содержание - хранились вместе, потом отдельно ... теперь даже результаты отделены от данных ...

... есть язык программирования процедурный а есть декларативный ...

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

... есть "правильно" с т.з. производительности и общей политики а есть "правильно" с т.з. простоты и быстроты ...

... гармония в середине ...

... никогДА не думал что товарищЬ это оскорбление - господин hogik ...

... вОт ...
Ответили: (21)
# Ответить
19. hogik 20.10.2009 00:10
(17)
"3 оператора, подойдут только если нам нужен итог"
"Пример в статье для самого простого случая."
Ну и мой пример для этого самого случая. ;-)
"говорю, что есть задачи, где он менее эффективен и удобен, чем запросный метод."
Именно - так. Но мы то говорим о конкретной задаче, где запросный метод НЕ эффективен и НЕ удобен. И Ваша статья, на мой взгляд, это подтверждает.

Спасибо за интересную беседу. Желаю успехов.
Ответили: (20)
+ 1 [ anig99; ]
# Ответить
20. anig99 20.10.2009 07:08
(19) да, видимо, немного нужно изменить статью - оговорку в начале более подробную сделать. Статья я ведь не о конкретной задаче (пример, это всё же пример - максимально упрощен, чтобы алгоритм понятнее был)
# Ответить
21. anig99 20.10.2009 07:22
(18) дзен-программирование, программирование по фен-шую, дао процедуры и функции...(: Не удержался (:
Но идея верная.
Ответили: (22)
# Ответить
22. Шёпот теней 20.10.2009 08:02
(21) ... ))) ...

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

... )))

... вОООттАААкойФенШуй ...
# Ответить
23. artbear 20.10.2009 08:23
(0) Тогда еще добавить, что при больших выборках применение данных методов вполне способно очень сильно загрузить сервер :(
Согласен, что данные методы очень удобны для использования в универсальных отчетах типа СКД, т.к. исключается программная обработка данных и позволяет уменьшить время разработки, а удобство увеличить.
Сам использую их таким образом.
Ответили: (24)
# Ответить
24. anig99 20.10.2009 08:40
(23) несколько раз в статье написано о времени выполнения запроса (нагрузке на сервер), а так большая часть статьи написана об ОПТИМИЗАЦИИ, чтобы время выполнения и нагрузка на сервер были минимальны.
# Ответить
25. Z-z-z 21.10.2009 12:54
В 7-ке не было вариантов - описанную задачу можно было решить только кодом. В 8-ке можно и кодом и запросом. Запросом получаем и более гибкое по возможностям решение и более быстрое.
Кстати в моем отчете http://www.infostart.ru/public/21968/ используется вариант автоматического ограничения периода без потери "точности" (можно принудительно ограничить период с потерей части детализации если производительность не достаточна).
Ответили: (26)
# Ответить
26. anig99 21.10.2009 13:41
(25) ну собственно это один из тех отчетов на которые я намёкивал (: Просто на моей базе без оптимизации одним запросом вообще труба, а вариант с искусственным ограничением числом дней не подходит по идеологическим соображениям
# Ответить
27. Ish_2 14.11.2009 22:00
Как же я пропустил ! Очень нужная статья.
Я извиняюсь , но всё читал мельком, кроме текста запроса.
Да простит меня автор , но всё же лучше придерживаться рекомендаций 1с , и оформлять пакетные запросы , используя временные таблицы.
На эту тему на ИС ,кажется , сказано уже немало.

Смутило также , упоминание в комментариях "загрузки сервера" без уточнения :"приложений" или "БД".
Думаю, метод оптимизации зависит от реализации "трехзвенки" .
Возможна ситуация , когда выгоднее загрузить выделенный сервер БД запросом , чем писать оптимизационный код , используемый в сервере приложений.
Ответили: (28)
# Ответить
28. anig99 15.11.2009 01:06
(27) конкретно код в статье не мой, лень было писать простой код (: В обработке по дебиторке (ссылка в статье), где всё это реализовано - пакетные запросы и временные таблицы.
А про комментарии...Я не подкован теоретически. Поэтому готов почитать хороший материал с примерами про производительность выполнения кода в различных вариантах.
Запрос, выполнение кода на машине, выполнение на сервере, один запрос, множество подзапросов в цикле, множество подзапросов в цикле на сервере....
# Ответить
29. Ish_2 15.11.2009 01:29
А кто здесь подкован теоретически ?
Я говорил про то , что сервер приложений и сервер баз данных могут находиться как на разных компьютерах так и на на одном.
Это обстоятельство может быть существенным при выборе варианта оптимизации.
Материалы с примерами производительнсти для разных вариантов реализации "трехзвенки"(клиент-сервер приложений-сервер баз данных) тоже бы почитал с удовольствием.
# Ответить
30. Ish_2 18.11.2009 01:12
Саш, я по-простому ?
На мой взгляд, лучшим вариантом оптимизации будет следующий :

Получим из виртуальной таблицы Обороты регистра ПродажиПоДисконтнымКартам правильно отсортированную таблицу значений Тоб
со структурой Карта, Период , СуммаОборот.
Добавим в Тоб типизированную колонку СуммаНакопления.
Теперь пишем :
ТекКарта = НеОпределено;
Для каждого Строка из Тоб Цикл 
      Если Строка.Карта <> ТекКарта Тогда 
             СуммаНакопления = Строка.СуммаОборот;
             ТекКарта = Строка.Карта;
      Иначе
             СуммаНакопления = СуммаНакопления + Строка.СуммаОборот;
      КонецЕсли;
      Строка.СуммаНакопления = СуммаНакопления;
КонецЦикла;
...Показать Скрыть

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

Итак , если сравнивать время исполнения запроса в тексте темы и алгоритм :

1. Выгрузка из запроса и Получение Тоб
2. Приведенный код
3. Загрузка в запрос таблицы Тоб и получение временной таблицы

То выигрыш при 100 000 записей в Тоб должен составить не менее 3 раз.
Если количество записей 1 000 000 и более то выигрыш должен составить не менее 5 раз.
Ответили: (37)
# Ответить
31. anig99 18.11.2009 09:27
(31) здесь я абсолютно согласен. С диким замедлением я тут же столкнулся, когда попытался получить нарастающие итоги в запросе. Покумекав и погуглив, я выяснил причину, но единственным решением нашел ограничением срока для уменьшения выборки.
Т.к. в тот момент я осваивал пакетные запросы и решил всё-таки ещё подумать, как можно обойти это ограничение, чтобы можно было обойтись средствами быстрого создания отчетов 1с 8. Результатом стал алгоритм последовательного приближения.
Плюсом этого алогоритма является то, что применить его можно как средствами пакетных запросов, так и простым кодом.
Если сравнивать запрос с последовательным приближением и выполнения кода без хитрых оптимизаций, то запрос выигрывает.
Это не теория. Я сравнивал по производительности отчеты по дебиторке и свои (разные варианты), и чужие. Пока быстрее всего - оптимизированный запрос.
Вопрос остается в другом - стоит ли отчет такой мудренной оптимизации. Для дебиторки - стоит. С получаса я сократил время до 10-20 сек и теперь могу сравнивать в одном отчете разные периоды достаточно быстро. Со старым отчетом мне даже в голову бы не пришло получить график просроченной дебиторки в разрезе дней за 3 месяца. А тут - ноу проблем.
Ответили: (32) (31)
# Ответить
32. Ish_2 18.11.2009 14:47
(31) Саша , я тебе могу задать с десяток вопросов. Но лучше о другом.
В чем -то я согласен с Чебуром.

Статья должна быть такой . Выкинуть словесную дребедень .
Оставить : Подробный пример описания метода нарастающих итогов.
В примере выкинуть регистры - оставить только абстрактные таблицы.

Постановка задачи. (абстрактная, выкинь ты эти ПродажиПоДиск...)
Дано : таблица Т1 , структура Поле1 , Поле2 и т.д.
таблица Т2 , структура Поле1....
Нужно получить Таблицу 3 со структурой ....

В теме автора допускается вставка "таблиц". Заполнил для наглядности
Т1 и Т2 простенькими значениями и пошел текст запроса с показом изменений в демо-таблицах Т1 и Т2.

Вот так будет по-взрослому.
Ответили: (35) (33)
# Ответить
33. anig99 18.11.2009 16:08
(32) а можно поподробнее про авторов и таблицы (можно в личку), а то не всё понял, немного сумбурно.
Словесную дребедень почищу, но только для стандартного запроса по нарастанию. Дальнейшие алгоритмы сложно описать более коротко.
# Ответить
34. Ish_2 18.11.2009 16:44
Зачем в личку ? Тут ничего неприличного нет.
Теперь я тебя не понял. Постараюсь по-другому.

Тема должна должна быть понятна читателям. См.(1)
Как её сделать наглядной и понятной ?
Ты сможешь описать её на уровне таблиц ?
Дана : Т1 со структурой ... Т2 со структурой..
Получить Т3 со структурой ..
# Ответить
35. Ish_2 18.11.2009 19:36
Я, конечно, ничего не понял про метод нарастающих итогов , но начал подозревать ,что мы говорим про разные задачи.
Я в (32) взял твой пример с запросом , по тексту статьи следует что дело именно в нем , показал как те же данные можно получить с помощью кода. И предполагаю , что проще , быстрее, надежнее
таблицу Тоб - не получить. Заметь Тоб получена не для одной карты как у тебя в запросе , а для всех карт сразу.

Ты мне говоришь про что ?
что есть еще какой-то метод получения Тоб ?
или ты имеешь ввиду какую-то другую задачу ?
Ответили: (36)
# Ответить
36. Александр Медведев 18.11.2009 20:43
(35) хмммм.... Я говорю о том, что как раз есть методы быстрее чем привычные, как для кода, так и для запросов. Если стоит просто задача получить итоги с нарастанием без дополнительных ограничений, то просто в цикле пройтись по таблице - несложно. Если есть условие сделать это в запросе (например для того, чтобы написать отчет только с помощью конструкторов без кодинга), то....ну там в статье написано. Если отчет простой, то зная как только запросом получить нарастающие итоги можно существенно облегчить себе жизнь при его создании.
НО.... можно наложить ещё одно условие - большой объём данных. Оба варианта при этом дают неудовлетоворительные результаты по скорости. Причём запрос начинает существенно проигрывать по скорости... Для оптимизации и кода, и запроса можно применить метод последовательного приближения.
Ответили: (37)
# Ответить
37. Ish_2 18.11.2009 21:46
(36) Да .. опять загадочно.

Ты утверждаешь :

1. что временную таблицу Тоб из (30) (внимание ! именно её, содержащую информацию для всех карт по периодам) ты получишь быстрее ? для большого объема информации ?
Так ?

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

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

Если так , то по-моему скромному мнению , быстрее этого простого способа что-то придумать тяжело.
Ответили: (39)
# Ответить
38. Ish_2 19.11.2009 00:37
Впрочем , получение Тоб - это только часть алгоритма.
Можно прикинуть следующий вариант : запрос, выбирающий нужные движения из вирт.таблицы Обороты.
И лишь затем код , получающий Тоб

Выбрать ДисконтнаяКарта, СуммаОстаток Поместить Остатки ИЗ Регистр.ПродажиПоДисконтнымКартам.Остатки(&Дата) 
//
Выбрать Об.ДисконтнаяКарта,Об.Период, Остатки.Сумма из 
РегистрНакопления.ПродажиПоДисконтнымКартам.Обороты(, , Регистратор)
как Об  ВнутреннееСоединение Остатки по Об.ДисконтнаКарта=Остатки.ДисконтнаяКарта
Итоги по Об.ДисконтнаяКарта
...Показать Скрыть


И далее понятный код получения Тоб из дерева выборки.
ВыборкаКарт = Запрос.Выполнить.Выбрать()
Пока ВыборкаКарт.Следующий() Цикл
       ВыборкаДокументов = ВыборкаКарт.Выбрать();
       Пока ВыборкаДокументов.Следующий() Цикл
              ....// создаем строку Тоб
              Если //Условие// Тогда
                Прервать;
              КонецЕсли;
      КОнецЦикла;
КОнецЦикла ;
...Показать Скрыть

Итак, Саша, мы сделали очень легкий запрос к остаткам вначале, затем
сделали всего один запрос с внутренним соединением. Да база ,очень большая, но и запрос простой без суммирования вовсе - раз , условие внутреннего соединения простое - два. Особо обращаю внимание мы обратились к базе с простыми запросами на выборку всего два раза
И в конце простой обработкой с прерыванием цикла по условию создали всю таблицу Тоб.
Ей-Богу , что можно придумать быстрее и проще ? Как ?
Какие нарастающие итоги ? Какие последовательные приближения?
Зачем это всё ?
Не томи.
Ответили: (59) (45) (41) (40)
# Ответить
39. Александр Медведев 19.11.2009 09:18
(37)
В статье же вроде написано всё.
Необходимость оптимизации требуется не для запроса с дисконтными картами - это всего лишь простой пример получения нарастающих итогов в запросе. Запрос по производительности сильно зависит от объема данных. Поэтому у нас получается так:
Код
+Скорость выполнения - скорость выполнения растёт линейно в зависимости от объема данных
-Скорость написания программистом отчета - если всё остальное в отчете реализуемо в рамках запроса и писать код не нужно, то для нарастающих итогов придется писать дополнительную процедуру, потом процедуру вывода отчета и т.д.

Запрос
+Скорость написания программистом отчета - весь отчет можно сделать автоматом на основе одного запроса
-Скорость выполнения запроса с нарастающими итогами - скорость растёт геометрически или экспоненциально в зависимости от объема данных

Остается только выбрать какой из вариантов более подходит под конкретную задачу.

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

З.Ы. Ну уж не знаю как объяснить необходимость оптимизации, если вместо 30 минут с помощью кода получаем за 10-20 секунд с помощью оптимизированного запроса.
Ответили: (41)
# Ответить
40. artbear 19.11.2009 09:46
(38) Уже говорили, что подобная схема с нарастающими итогами часто бывает нужна именно в запросах для использования универсальных отчетов.
например, чтобы в СКД сделать некий отчет без доп.кодирования.
Данная задача должна применяться для какого-то ограниченного, не слишком большого множества данных, иначе получим проблемы с производительностью.
Ответили: (54) (41)
# Ответить
41. Ish_2 19.11.2009 16:24
(39) Приведи описание и текст запроса. Это просто слова.
Напиши еще одну статью , уже без разбора альтернативных вариантов.
Только тексты запросов и объяснения к ним. Остальное - лишнее.
(40)
Данная задача должна применяться для какого-то ограниченного, не слишком большого множества данных, иначе получим проблемы с производительностью.


Это про что ? Про предложенный алгоритм в (38) ?
Любое множество данных есть не слишком большое.
Что-то более вразумительное к цитате добавить тяжело.
Ответили: (42)
# Ответить
42. Александр Медведев 19.11.2009 19:23
(41) Отдельно запрос есть и опубликован. Ссылка в тексте.
Если я вынесу в отдельную статью описание запроса, то это потребует тех же объяснений...Что зачем и почему, как решить по-другому...чтобы понять проблему нужно полностью её описать. Это как объяснять человеку, который не видел электричества работу атомного реактора без объяснения зачем требуется такое устройство и где его лучше применять и строить и как без него обоитись
Ответили: (43)
# Ответить
43. Ish_2 19.11.2009 20:48
(42) Саша, я просто капризный. Много слов меня раздражает. Я ведь неслучайно привел свой текст запроса и обработки. Чтобы без лишних рассуждений было все абсолютно понятно.
По-прежнему считаю , что так представление метода (алгоритма) не делается. Но о вкусах не спорят.

Я привел тебе алгоритм . Скажи метод нарастающих итогов какую даст прибавку в быстродействии , по сравнению с моим запросом и обработкой ?
В конкретно твоей базе ? 5 раз, 10 раз ? сколько ?

Ты мне дай одну ссылку и имя файла которое надо скачать.
А то там много чего написано и ссылок внутри.
Ответили: (44)
# Ответить
44. Александр Медведев 19.11.2009 23:53
(43) кол-во слов сокращу, а содержание всё-таки оставлю (:
Метод нарастающих итогов - увеличит время выполнения.
Неоптимизированный код:оптимизированный по-моему запрос 20:1
Оптимизированный по-твоему код:оптимизированный по-моему запрос минимум 5:1

http://infostart.ru/public/download.php?file=54832
Ответили: (83) (69) (68) (45)
# Ответить
45. Ish_2 20.11.2009 15:02
(44) Замечу , 5:1 - это подозрительно и очень круто. Но если это так , то конечно , сложность алгоритма без всякого сомнения оправдана.

Но уменя еще вопрос . Саша , а рассматривался такой вариант :

Выбирается Период "П1" , допустим месяц . И для этого периода запускается алгоритм (38). Получили Тоб.
Из таблицы Тоб выбираются карты , для которых периода "П1" - "не хватило" и на текущий долг не набралось достаточно документов.
Для полученной временной таблицы непогашенных карт алгоритм (38) запускается еще раз с периодом "П2" , допустим "год".
И далее период "П3" - уже весь интервал для оставщихся карт с непогашенным долгом.
Не это ли есть последовательные приближения ? При таком подходе
Периоды П1,П2,П3 должны быть такими , чтобы количество записей в Тоб на каждом шаге уменьшалось в десятки , сотни раз
Речь идет о конкретной базе.О твоей. При таком подходе соотношение времен выполнения моего и твоего алгоритма должно быть
1:2.
А при удачном подборе периодов П1,П2,П3 можно жобиться 1:5.

Это прогноз , разумеется.
Ну ,как ? согласен ?
Ответили: (47)
# Ответить
46. Александр Медведев 20.11.2009 15:52
По поводу твоего алгоритма - удачный. Недостаток действительно только в правильном подборе сроков деления. На это нужны эксперименты... Можно его модифицировать приращивая периоды не с увеличением интервальности, а равными долями. Т.е. не месяц, год и т.д. А месяц, предыдущий месяц, позапредыдущий месяц и т.д.
Только вот опять тут нельзя реализовать данный алгоритм в рамках одного запроса. А так очень неплохой алгоритм.

Я тут на тебе попробую различные варианты объяснения своего алгоритма. Какой понятнее и проще...

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

Контрагент Полных месяцев долга

Контрагент Полных дней долга

Контрагент Документы долга в самый давний день долга

Из этих таблиц уже можно получить полный список документов долга.
# Ответить
47. Ish_2 20.11.2009 20:48
Ок. Черт с тобой. Пробуй на мне свой алгоритм.
Я немного туповат , но буду стараться.
Свои замечания по (45) и как они у тебя реализованы оставю чуть позже.
# Ответить
48. Ish_2 20.11.2009 22:10
Поехали . Итак ниже
1. Ты обращаешься ко всей (!) вирт.таблице Обороты с периодичностью "Регистратор" и практически всю(!) ее копируешь во временную таблицу.
ВЫБРАТЬ
	ВзаиморасчетыСКонтрагентамиОбороты.Период КАК Период,
	ВзаиморасчетыСКонтрагентамиОбороты.Контрагент КАК Контрагент,
	ВзаиморасчетыСКонтрагентамиОбороты.Регистратор КАК Регистратор,
	ВзаиморасчетыСКонтрагентамиОбороты.СуммаУпрОборот КАК СуммаУпрОборот,
	ГОД(ВзаиморасчетыСКонтрагентамиОбороты.Период) КАК ГодПериод,
	МЕСЯЦ(ВзаиморасчетыСКонтрагентамиОбороты.Период) КАК МесяцПериод,
	ДЕНЬ(ВзаиморасчетыСКонтрагентамиОбороты.Период) КАК ДеньПериод
ПОМЕСТИТЬ Взаиморасчеты
ИЗ
	РегистрНакопления.ВзаиморасчетыСКонтрагентами.Обороты(, КОНЕЦПЕРИОДА(&Дата2, ДЕНЬ), Регистратор, Контрагент В ИЕРАРХИИ (&Контрагент)) КАК ВзаиморасчетыСКонтрагентамиОбороты

ИНДЕКСИРОВАТЬ ПО
	Контрагент
;
...Показать Скрыть


теперь эту огромную временную таблицу ты группируешь по периодам :
ВЫБРАТЬ
	Взаиморасчеты.ГодПериод КАК ПериодГод,
	Взаиморасчеты.МесяцПериод КАК ПериодМесяц,
	Взаиморасчеты.ДеньПериод КАК ПериодДень,
	Взаиморасчеты.Контрагент,
	СУММА(Взаиморасчеты.СуммаУпрОборот) КАК СуммаУпрОборот
ПОМЕСТИТЬ УвеличенияДолгаДень
ИЗ
	Взаиморасчеты КАК Взаиморасчеты
ГДЕ
	Взаиморасчеты.СуммаУпрОборот > 0

СГРУППИРОВАТЬ ПО
	Взаиморасчеты.Контрагент,
	Взаиморасчеты.ГодПериод,
	Взаиморасчеты.МесяцПериод,
	Взаиморасчеты.ДеньПериод
;
...Показать Скрыть


Дважды обращаясь к огромному количесву данных- ты проиграл очень много .
В данном случае достаточно одного запроса к вирт. таблице Обороты с периодичностью Регистратор.
ВЫБРАТЬ
	ВзаиморасчетыСКонтрагентамиОбороты.Контрагент КАК Контрагент,
	ГОД(ВзаиморасчетыСКонтрагентамиОбороты.Период) КАК ГодПериод,
	МЕСЯЦ(ВзаиморасчетыСКонтрагентамиОбороты.Период) КАК МесяцПериод,
	День(ВзаиморасчетыСКонтрагентамиОбороты.Период КАК ДеньПериод
	Сумма(ВзаиморасчетыСКонтрагентамиОбороты.СуммаУпрОборот) КАК СуммаУпрОборот,
ПОМЕСТИТЬ Взаиморасчеты
ИЗ
	РегистрНакопления.ВзаиморасчетыСКонтрагентами.Обороты(, КОНЕЦПЕРИОДА(&Дата2, ДЕНЬ), Регистратор, Контрагент В ИЕРАРХИИ (&Контрагент)) КАК ВзаиморасчетыСКонтрагентамиОбороты
ГДЕ
	ВзаиморасчетыСКонтрагентамиОбороты.СуммаУпрОборот > 0
СГРУППИРОВАТЬ ПО
	Контрагент,
	ГодПериод,
	МесяцПериод,
	ДеньПериод

ИНДЕКСИРОВАТЬ ПО
	Контрагент
...Показать Скрыть


Мелкие замечания :
Функцию КонецПериода() применять в запросе - как-то не очень.
Индексировать - применяется в том случае если в дальнейшем
требуется многократное ( в разных запросах) соединение или фильтр по этому полю. А в принципе оптимизатор запроса сам построит временный индекс по этому полю.


Вот ,блин. Редактировать жутко неудобно и цвета выделения не работают.
Ответили: (53) (52) (51)
# Ответить
49. Александр Медведев 20.11.2009 23:32
Про двойное обращение замечание верно. Но если я правильно помню, то общая таблица взаиморасчетов потом используется ещё - чтобы выводить весь список документов за период долга. Про индексировать... ну я по наитию его туда вставил.
КонецПериода вставил как двойной предохранитель.
Ответили: (50)
# Ответить
50. Ish_2 21.11.2009 00:23
(49) И всё-таки двойное обращение ненужно . Проще потом обратиться еще раз прямо к самой виртуальной таблице Обороты. По размерам эти огромные таблицы одинаковы.
# Ответить
51. artbear 21.11.2009 08:25
(48) Цитата: "А в принципе оптимизатор запроса сам построит временный индекс по этому полю"
я лично не стал бы рассчитывать на это неявное поведение оптимизатора, у его и других задач/приоритетов полно.
Если индекс все равно нужен, т.к. будет использоваться в фильтрах или соединениях, нужно задавать его явно!
Ответили: (53)
# Ответить
52. artbear 21.11.2009 08:27
(48) Использование "КонецПериода" - также вполне нормальное явление.
Автор гарантирует, что запрос отработает нормально для любой даты.
Ответили: (53)
# Ответить
53. Ish_2 21.11.2009 10:02
В (48) Придирки.
(51) Согласен, но сам ставлю Индексировать лишь придальнейшем неоднократном использовании .
(52) Согласен.
# Ответить
54. Ish_2 21.11.2009 12:02
К загадочному (40).
Я так понимаю , что смысл затеи сделать все вычисления в одном запросе только один : "уйти с клиента" - перенести все вычисления на сервер. Причем сервер базы данных.
# Ответить
55. Ish_2 21.11.2009 23:07
Саша, на всякий случай.. Мало ли ..
Мне тут как то приходилось объяснять Шепоту , что такое оппонент и в чем его задача. Задача его "наводить критику". Вот я навожу.

Смотрел , смотрел текст запросов. Затем еще раз прочитал твои объяснения в статье.

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

Критика 2. Вложенные запросы в тексте призводят жуткое впечатление.
Давно пора перейти к временным таблицам. Легче рассматривать , проще искать ошибки и т.д. Уж сколько говорилось на эту тему и фирмой 1с и пользователями ИС...

Критика 3. Теперь по сути.

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

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

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

Критика 4. Дойдя до получение таблиц УвеличениеДолгаДень, Ув..месяц, Ув..Год, я не сомневался что последует дальше. Ан нет. Мне всерьез непонятно ,зачем так сложно ? Спорить тут бестолку. Алгоритм у тебя работатет.
Про оптимальный, на мой взгляд, алгоритм лучше самому писать статью.
Вот брошу пить - я за Вас возьмусь !
Если напишу - приглашу тебя и назначу самым злобным оппонентом.
# Ответить
56. I_G_O_R 22.11.2009 01:41
ксати, в ЗУПе для подсчета доходов физлица по периодам нарастающим итогом используется такой же метод как в статье, так что зачёт
Ответили: (57)
# Ответить
57. Ish_2 22.11.2009 01:50
(56) Не-а. Не убедил.
Кстати, Игорь помнишь я тебе говорил про перепроведение по регистру партий - как получить все движения всех перепроводимых документов одним запросом ? И на чем споткнулся и все полетело коту под хвост ? Именно на этом : запросы с нарастающими итогами. Такое перепроведение - одним запросом все движения - уступало по быстродействию штатной обработке (с использованием таблицы значений) многократно.
И хотя задача перепроведения чуть навороченнее, но задаче в теме родственная. И суть та же как обойти медленный расчет нарастающих итогов.
Ответили: (58)
# Ответить
58. I_G_O_R 22.11.2009 01:58
(57) помню конечно, вот хочу тест на ночь глядя сделать, сравнить запросом и кодом.
Ответили: (59)
# Ответить
59. Ish_2 22.11.2009 02:09
(58) Я здесь приводил код в (38) кажется втупую весь регистр в выборку
и за один проход получить выходную таблицу. Вот по прежнему слабо верится , что он уступит запросу в этой теме.
Хотя можно сделать три запроса : Сравнить текущийдолг с оборотом за месяц - все попавшие выгрузить, остальные сравнить с оборотом за год и т.д
# Ответить
60. I_G_O_R 22.11.2009 02:33
болт ребята :o , если документы имеют одну и ту же дату и время, то таблицы соединять по периоду будет ерунда полная, так что только кодом. Я взял сделал 10 документов с одинаковой датой и временем, итоговая сумма оказалась во всех строчках одинаковой :!: , делайте выводы, господа :!:
Ответили: (66) (61)
# Ответить
61. Ish_2 22.11.2009 02:38
(60)Постой, Если ты обращаешься в конструкторе запроса к таблице обороты там должно быть Поле МоментВремени. Сравнивать, упорядочивать надо естественно по нему.
Ответили: (63)
# Ответить
62. Ish_2 22.11.2009 03:05
Это вопрос Саше : почему у тебя в тексте запроса нигде не применяется МоментВремени. И что будет если Два или несколько документов имеют одинаковую дату и время ?
Ответили: (65)
# Ответить
63. I_G_O_R 22.11.2009 04:21
(61) а вот и нету :D , значит надо брать таблицу записей.

а еще посмотрите в технологическом журнале как генерируется запрос для таблицы ОстаткиИОбороты, ведь, как мы знаем, поле КонечныйОстаток - это как раз остаток нарастающим итогом. Да, кстати, никто не сказал про использование таблицы ОстаткиИОбороты, а ведь с помощью неё можно добиться желаемого результата.
Ответили: (65) (64)
# Ответить
64. Ish_2 22.11.2009 11:21
(63) Так дело не пойдет . Загадками бросаешься.
Я считаю , что Таблицу ОстаткиИОбороты эффективно использовать в данной задаче не удастся. Ну.. так мало ли , что я считаю . Если думаешь, что из этой таблицы можно что-то выудить - пиши статью.
И я потянусь за тобой со своей статейкой : нет, товарищи , так делать нельзя. Глядишь , скука и пройдет...
Только условие Саши - весь алгоритм в одном флаконе (запросе) должно быть выполнено.
Ответили: (77)
# Ответить
65. Александр Медведев 22.11.2009 11:44
(62) Гы-гы...Думал когда же всплывет (: Для того, чтобы отсортировать документы с одинаковой датой сравниваю ещё по ссылке <=. Ведь что есть Момент времени? Виртуальный тип, который содержит в себе Дату и ссылку.
(63) Итоги то с нарастающим, но там все итоги, а нам нужны только по документам увеличивающим задолженность
С разными виртуальными таблицами есть ещё лажа с Границами, в таблице остатки нельзя задать условие не границу, её туда надо в виде параметра запихивать, а в ОстаткахИОборотах есть соответствующий параметр, который преобразовывает дату в границу. Вот тут и есть глобальная подстава для СКД... Штатным конструктором нельзя границу в запрос СКД передать, только с помощью кода. Поэтому когда быстро ваяешь запрос по виртуальной таблице Остатки в СКД, нужно помнить, что граничные значения не получишь.
Ответили: (66)
+ 1 [ jk3; ]
# Ответить
66. Ish_2 22.11.2009 12:13
(65) Будем считать , что (60) Игорь писал НЕ про твою обработку и что-то перепутал.
Ага , вот нашел у тебя в условии соединения :
				И (ВЫБОР
					КОГДА ПериодыРегистратор.Период < УвеличениеРегистратор.Период
						ТОГДА ИСТИНА
					ИНАЧЕ ВЫБОР
							КОГДА ПериодыРегистратор.Период = УвеличениеРегистратор.Период
								ТОГДА ПериодыРегистратор.Регистратор <= УвеличениеРегистратор.Регистратор
							ИНАЧЕ ЛОЖЬ
						КОНЕЦ
				КОНЕЦ)
...Показать Скрыть


Такое выражение в условии соединения есть предложение оптимизатору запроса - отдохни , это не для тебя - мы будем тормозить ! и обращаться не к индексу ,а к каждой записи самой таблицы!
Чтобы дать хоть какой то шанс бедному оптимизатору , на мой осторожный взгляд, лучше написать :
 И ( ПериодыРегистратор.Период < УвеличениеРегистратор.Период ИЛИ
    ПериодыРегистратор.Период = УвеличениеРегистратор.Период И
    ПериодыРегистратор.Регистратор <= УвеличениеРегистратор.Регистратор)
Ответили: (67)
# Ответить
67. I_G_O_R 22.11.2009 15:37
(66) я такой код вообще нигде невидел :o
Ответили: (68)
# Ответить
68. Ish_2 22.11.2009 15:43
(67) Я скачал из ссылки в (44)
Ответили: (71)
# Ответить
69. I_G_O_R 22.11.2009 15:44
а в отчете по ссылке из (44) выдает везде одинаковые цифры, где тут итоговая сумма?
Ответили: (83) (81) (70)

Прикрепленные файлы:

1.png
# Ответить
70. Ish_2 22.11.2009 15:47
(69) У меня нет возможности проверить и я смотрю только текст запроса.
# Ответить
71. I_G_O_R 22.11.2009 15:49
(68) да я видел ссылку, скачал а там пусто :o , потом оказывается нашел глюк в платформе 8.1.15. Делал так:
1. Меню-Файл-Открыть
2. Выбираю тип файла: Внешняя обработка
3. что-то не вижу :o , в поле "Имя файла" набираю первые буквы и вот он, нажимаю открыть, а там пусто :o

Если открыть без фильтра или с правильным фильтром(Внешния отчет), то открывается все ОК :D
# Ответить
72. I_G_O_R 22.11.2009 15:55
вот ещё, может он и правильный, может это я что-то не понимаю :?:
Ответили: (75) (73)

Прикрепленные файлы:

1.png
# Ответить
73. Ish_2 22.11.2009 16:00
(72) Я чего -то поплыл . А входящее плат.поручение и как туда попало ?
Ответили: (74)
# Ответить
74. I_G_O_R 22.11.2009 16:08
(73) у нас в России платежное поручение влияет на взаиморасчеты
Ответили: (75)
# Ответить
75. Ish_2 22.11.2009 16:21
(74) Виноват.
Надо съездить в Ростов-на-Дону(Россия) , посмотреть как там люди живут.
А у тебя какие вопросы по (72) ?
Ответили: (76)
# Ответить
76. I_G_O_R 22.11.2009 16:26
(75) я думал, в отчете должна быть сумма нарастающим итогом.
# Ответить
77. I_G_O_R 22.11.2009 16:33
(64) вот пример как можно использовать таблицу ОстаткиИОбороты для расчета суммы нарастающим итогом
Ответили: (78)

Прикрепленные файлы:

СуммаНарастающимИтогом.erf
# Ответить
78. Ish_2 22.11.2009 16:58
(77)Это что ? Чего то я опять потерялся.
Зачем нам таблица Контрагент, Регистратор, Оборот, КонечныйОстаток ? ЧТо Она дает ?
Нам нужно на текущий долг контрагента набрать документов и вывести .
А ты что привел ?
Ответили: (80) (79)
# Ответить
79. I_G_O_R 22.11.2009 17:09
(78) смотри картинку, почти тоже самое как в статье, только период наоборот
Ответили: (87) (81)

Прикрепленные файлы:

1.png
# Ответить
80. I_G_O_R 22.11.2009 17:30
(78) ну тогда сформулируй четко задачу, можно даже сделать новую базу, с одним документом, с одним справочником "Контрагент", и с одним регистром накопления "Взаиморасчеты".
Ответили: (82)
# Ответить
81. Ish_2 22.11.2009 17:30
Не-а. Я растерялся и так и не нашелся (79).
Давай-ка сам где у тебя что ? Зачем ты складываешь конечные остатки по каждому документу ? Посмотри еще раз (69) и найди 10 отличий
Ответили: (83)
# Ответить
82. Ish_2 22.11.2009 17:38
(80) Мы друг друга не понимаем и каждый говорит о чем то своем.

Контрагент Вася Пупкин имеет долг 100 рублей
Ему были отпушены две последние накладные
Накл 1 на 40 р.
накл 2 на 70 р.
Нужно получить таблицу
Контрагент Долг
Вася Пукин                     100 р.
   Накл 1                         40р.
   Накл 2                         60р.

Т.е список неоплаченных накладных .
Ответили: (84)
# Ответить
83. I_G_O_R 22.11.2009 17:41
(81)я вообще-то смотрю в статью :o

Реализация товаров и услуг №1 500р 2200р
Реализация товаров и услуг №2 1000р 1700р
Платежное поручение исходящее №1 -500р 700р
Реализация товаров и услуг №3 1200р 1200р


а в (69) это я скачал отчет из (44) и сформировал отчет, в чем смысл этого отчета, где там сумма нарастающим итогом, и зачем так много кода я так и не понял.
# Ответить
84. I_G_O_R 22.11.2009 17:44
(82) а какое это имеет отношение к нарастающим итогам?
Ответили: (85)
# Ответить
85. Ish_2 22.11.2009 17:54
(84) А такое :
См. текст запроса в статье :
Вначале мы найдем при помощи запроса таблицу
Документ Сумма НарастающийИтог
Накл1           40                     40 
Накл 2          70                     110

Затем исхитримся и опять запросом сраниваем долг 100 с колонкой накопленные итоги , "попадем " на накл 2 отбросим 10 рублей и запишем
Накл1           40
Накл 2          60  
Ответили: (91)
# Ответить
86. Ish_2 22.11.2009 18:02
Напиши запрос , чтобы из таблицы
01.01.09 Накл 1 10
01.02.09 накл 2 20
01.03.09 накл 3 30

Получить нарастающие итоги :
01.01.09 Накл 1 10 10
01.02.09 накл 2 20 30
01.03.09 накл 3 30 60

И все поймешь.
Ответили: (87)
# Ответить
87. I_G_O_R 22.11.2009 18:12
(86) а в скриншоте из (79) разве не оно?
Ответили: (88)
# Ответить
88. Ish_2 22.11.2009 18:23
(87) Нет.
Еще раз. на 100 рублей долга нужно набрать накладных , которые были отпущены клиенту .
И сказать : вот вам список накладных, которые клиентом не оплачены.
Из этого списка неолаченных накладных мы выбираем по дате те накладные которые отстоят от текущей даты на компе более чем на N дней суммируем их и говорим - а вот это просроченный долг !
N - разрешенной количество дней просрочки долга.
Ответили: (90)
# Ответить
89. Александр Медведев 22.11.2009 18:26
Извините, что выпадаю из дискуссию, у меня тут ремонт внезапно начался... Да и сдача книг и налога на прибыль на носу.
Ответили: (92)
# Ответить
90. I_G_O_R 22.11.2009 18:39
(88) мне интересно, где это в статье написано?
а во-вторых в отчете из 44 выводится Регистратор, объясните мне как может получится, что долг у контрагента 100 рублей, а у документов сумма 70 и 40? Или этот отчет тоже не решает этой задачи?
Ответили: (91)
# Ответить
91. Ish_2 22.11.2009 19:01
(90) Хорошо вот тебе полная картина
Вася Пупкин Долг 100
Имеет документы :
Накл. 1   40
Накл  2   70
Платеж  -10       

Нужно узнать какие накладные клиентом не оплачены и на какую сумму каждая накладная не оплачена (см. (85) вторая таблица) ?
И ты получишь :

Накл1           40 
Накл 2          60  
Ответили: (93)
# Ответить
92. Ish_2 22.11.2009 19:07
(89) Саш, ты нам только мешаешь ! :D
# Ответить
93. I_G_O_R 22.11.2009 21:18
(91) если решать твоим способом, то таблица ОстаткиИОбороты(хотя кто его знает) не поможет, но задачка интересная. В принципе, чем-то похоже на отчет из УТ "ПродажиПоОплате", только там наоборот выводятся полностью оплаченные.
Ответили: (100) (94)
# Ответить
94. Ish_2 22.11.2009 21:48
(93)Интересная в том смысле что :
1. База у Саши 120Гб.
2. Саша ни в какую не согласен кодировать и настаивает на том , что весь алгоритм должен умещаться в одном запросе. (вся нагрузка , как и в задаче получения всех движений регистра партий при перепроведении, ляжет на сервер базы данных).

3. Самое смешное в том , что сейчас я понимаю , что он прав.
И я готов отказаться от своих предложений как неоптимальных.
Эти предложения предполагают кодинг.
# Ответить
95. Ish_2 22.11.2009 22:15
Саша , ты меня уговорил . Буду писать статью
"Подведем итоги . Нарастающие." - о том каким должен быть текст оптимального запроса в данной задаче . В статье - Текст запроса и сопровождающие его иллюстрации в виде таблиц.
Приглашаю быть злобным оппонентом. Приглашаю также Игоря и Артура.
Через 2-3 дня сообщу дату публикации.
Ответили: (99)
# Ответить
96. Александр Медведев 23.11.2009 00:25
Бес...т.е. без проблем...(:
Ответили: (97)
# Ответить
97. Ish_2 23.11.2009 00:56
(96) Ага ! Обзываться уже начал , злобный Саша !
ты того .. не переборщи , а то плохо про тебя в статье напишу :
Так мол и так , Саша - нехороший человек.
Ответили: (98)
# Ответить
98. Александр Медведев 23.11.2009 07:20
(97) А я и не написал насчет кого или чего оговорился... (: Не надо всё на себя премерять...(:
Ответили: (100)
# Ответить
99. artbear 23.11.2009 10:27
(95) Жду
Ответили: (100)
# Ответить
100. Ish_2 25.11.2009 00:30
(99),(98),(93) Публикация будет доступна 25.11.09 в 10-00

Подведем итоги . Нарастающие.
http://infostart.ru/public/61295/
Ответили: (101)
# Ответить
101. Александр Медведев 25.11.2009 08:35
(100) а то я в новостях увидел, а прочитать не успел
Ответили: (102)
# Ответить
102. Ish_2 25.11.2009 13:39
(101) На сайте что-то происходит. Очередные трудности движка.
# Ответить
103. jk3 09.12.2009 12:08
Было бы неплохо к текстовому описанию схему нарисовать, хотя бы упрощенную
# Ответить
104. Ish_2 05.01.2010 01:01
Кстати, Саша. А ты не задумывался над тем , что задача получения просроченного долга есть лишь частный случай другой задачи ?
Задачи получения всех движений расходных докуметов по регистру партий за период
Действительно , в задаче просроченного долга для каждого контрагента :

S - сумма долга
С1,С2...Сk - последовательность сумм всех документов отгрузки.
Требуется найти такую последовательность С1,С2...Сn, чтобы
S = C1+C2+...+Cn
Грубо говоря , набираем накладные на сумму долга.

А если вместо S взять последовательность S1,S2...Sk (суммы документов прихода), то тогда получим задачу получения всех движений по регистру партий при перепроведении расходных документов.

И эта задача решается тоже при помощи нарастающих итогов.
И тоже одним пакетом запросов , набранном в конструкторе.
Ответили: (108)
# Ответить
105. Александр Медведев 07.01.2010 16:24
Угу... Тоже задумывался как можно прикрутить это к задаче перепроведения документов... Мне пока приходится после каждого проведения делать запрос по партиям заново... Запрос конечно маленький и быстрый...0,06-0,08 сек и производительность меня устраивает, но множество мелких запросов хотелось бы заменить одним, чтобы сразу получить список всех "неправильных" документов
Ответили: (106)
# Ответить
106. Ish_2 02.04.2010 10:41
(105) Саша, приглашаю похихикать http://infostart.ru/public/68225/
# Ответить
107. Qseft 05.10.2011 16:06
Пора бы 1С о ранжирующих функциях в запросах задуматься (по аналогии SQL)
# Ответить
108. alina0587 16.01.2014 00:27
(104) А можно где-то поподробнее прочитать про решение такой задачи запросом?
Заранее спасибо!
Ответили: (109)
# Ответить
110. ildarovich 04.03.2014 16:30
Если автор темы не возразит, размещу здесь ссылку на свой очень быстрый метод решения этой задачи запросом: http://infostart.ru/public/262300/. Данную статью я в свое время прочел, метод в голове отложился. Так что автору большое спасибо - в моей работе имеется и его вклад.
Ответили: (111)
# Ответить
111. anig99 04.03.2014 16:53
(110) прошу обратить внимание на МоментВремени(), чтобы избежать проблем с совпадающими датами.
Ответили: (112)
# Ответить
112. ildarovich 05.03.2014 13:35
(111) Я предложил, возможно, спорное, но кажущееся мне более правильное решение - не различать документы при совпадении даты. То есть, если в первой неоплаченной секунде у одного контрагента несколько документов, то посчитать отношение долга к общей сумме документов секунды и считать неоплаченной суммой каждого документа эту долю его суммы. Имеем: три документа одного контрагента в одной первой секунде по 100 рублей и долг 150 рублей. Тогда каждый документ будет не оплачен в сумме 50 рублей. А вообще это редчайшая ситуация и ломать по этому поводу копья вряд ли стоит.
Момент времени упорядочивает документы внутри секунды жестким, "случайным" и неуправляемым образом. Какие основания полагаться на этот порядок при решении о порядке погашения документов? Опять же, если бы случайность была бы "мягкой", то в среднем односекундные документы погашались предложенным мною способом.
Ответили: (113)
# Ответить
113. anig99 06.03.2014 08:34
(112) сразу 2 возражения. Момент времени упорядочивает документы внутри секунды совершенно определенным образом, и порядок это сохраняется всегда, т.к. зависит от GUID http://infostart.ru/public/84177/. Но это так, уточнение. А основное возражение такое - множество документов в одну секунду - это не редчайший случай. Во-первых, среди 1сников распространена практика приведения в порядок партий в течении одного дня сменой времени документов (поступление на начало дня, реализации на конец). Во-вторых, при проведении документов будущей датой в режиме неоперативного проведения время документа устанавливается на начало дня. В-третьих, вообще при неоперативном проведении задним числом новый документ устанавливает время за последним документом за эту дату. Если последний документ будет на конец дня, то и все последующие будут на конец дня. В-четвертых, в УПП какое-то время существовал небольшой баг - платежки писали в регистр взаиморасчетов время на начало дня, вне зависимости от времени самого документа.
Ответили: (114)
# Ответить
114. ildarovich 06.03.2014 15:16
(113) Я не то, чтобы спорю - все эти обстоятельства я тоже имею ввиду, но делаю другие выводы. Тут вопрос более тонкий и я хотел это подчеркнуть.
Момент времени упорядочивает документы внутри секунды совершенно определенным образом, и порядок это сохраняется всегда
А я пишу
Момент времени упорядочивает документы внутри секунды жестким, "случайным" и неуправляемым образом
Тут нет противоречия, "случайным" - поскольку GUID формируется на основе случайности (условно говоря, а вообще вроде бы там MD5 вычисляется с учетом системного времени). Потом он фиксируется и передвинуть документ внутри секунды нельзя (это о жесткости и неуправляемости). Ну а если пользователь не понимает правила упорядочивания - один раз так, потом так, и не может на это повлиять, то полагаться на момент времени не желательно (так мне кажется).
множество документов в одну секунду - это не редчайший случай
совершенно согласен, но для возникновения конкретной рассматриваемой проблемы требуется совпадения секунды не множества, а ПОДМНОЖЕСТВА документов, имеющих одного контрагента и один тип операции - отгрузка. Кроме того, проблема возникает только тогда, когда эта секунда становится первой секундой неоплаченности.

И, далее, предлагаемое решение не "пасует" в этой ситуации, а просто рассматривает односекундные отгрузки как единые документы с точки зрения взаиморасчетов. Это очень просто объяснить менеджерам. Они видят все (а не один произвольно выбранный) частично оплаченные документы и их общую сумму.
# Ответить
115. dr.death 20.10.2014 09:59
А как сюда прикрутить МоментВремени? Чтобы нв каждую строку с одинаковым по времени регистратором получить свой итог?
Ответили: (116)
# Ответить
116. anig99 20.10.2014 10:37
(115) dr.death, добавьте условие, чтобы для одинакового времени ещё сравнивались ссылки Регистратор1 < Регистратор2. Грубо Момент времени = Дата + Ссылка.
# Ответить
117. dr.death 20.10.2014 11:36
Спасибо, разобрался. У меня была маленько другая ситуация. Регистратор делал движения по табличной части, следовательно нарастающий итог был только по регистратору... добавил дополнительно сравнение по НомеруСтроки
# Ответить
Внимание! За постинг в данном форуме $m не начисляются.
Внимание! Для написания сообщения необходимо авторизоваться
Текст сообщения*
Прикрепить файл






IE 2016