gifts2017

Еще один способ расчета остатков на каждый день в запросе

Опубликовал Сергей (ildarovich) в раздел Программирование - Практика программирования

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

Разработчики платформы "1С: Предприятие 8" постарались сделать все, чтобы при решении рядовых задач не приходилось ломать голову, придумывая сложные алгоритмы. Но несколько нетривиальных задач все же осталось. Одной из них является задача расчета остатков на каждый день в запросе.

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

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

В первом основой является таблица оборотов. Исходные дневные обороты суммируются в интервале от начала до каждой даты периода. Этот подход в точности воспроизводит работу платформы по определению остатков внутри периода их хранения для формирования виртуальной таблицы остатков и оборотов. Отличие только в том, что суммирование выполняется для каждого дня. Примером такого подхода является решение задачи 6 из статьи [Минимализмы].

Во втором подходе основой является таблица остатков тех периодов, где были обороты. Остатки для пропущенных дней находятся по принципу срезов последних: для каждой даты находится ближайший в прошлом остаток. Примером этого подхода является решение из статьи [Остатки на каждый день периода одним запросом - универсальный]. 

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

Новый способ, предлагаемый в данной статье,  опирается на таблицу остатков, но НЕ ТРЕБУЕТ ПРЕДВАРИТЕЛЬНОГО ФОРМИРОВАНИЯ ТАБЛИЦЫ ДАТ. За счет многократного повторения одного простого запроса остаток одного дня распространяется (по принципу домино) на следующие дни. За счет этого пропуски в таблице остатков быстро заполняются.

Вот предлагаемый запрос:

ВЫБРАТЬ
	Номенклатура,
	Период,
	ВНаличииКонечныйОстаток КАК Было
ПОМЕСТИТЬ Шаг0
ИЗ
	РегистрНакопления.ТоварыНаСкладах.ОстаткиИОбороты(&НачалоПериода, &КонецПериода, День, , )

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
	Номенклатура,
	&НачалоПериода,
	0
ИЗ
	РегистрНакопления.ТоварыНаСкладах.ОстаткиИОбороты(&НачалоПериода, &КонецПериода, ДЕНЬ, , )
;

////////Повторяется Х раз////////
ВЫБРАТЬ
	Номенклатура,
	Период,
	ЕСТЬNULL(МАКСИМУМ(Было), МАКСИМУМ(Стало)) КАК Было
ПОМЕСТИТЬ Шаг1
ИЗ
	(ВЫБРАТЬ
		Номенклатура КАК Номенклатура,
		Период КАК Период,
		Было КАК Было,
		NULL КАК Стало
	ИЗ      
		Шаг0 //таблица, полученная на предыдущем шаге
	
	ОБЪЕДИНИТЬ ВСЕ
	
	ВЫБРАТЬ
		Номенклатура,
		ДОБАВИТЬКДАТЕ(Период, ДЕНЬ, 1),//каждый раз вдвое больше дней: 1, 2, 4 и так далее
		NULL,
		Было
	ИЗ      
		Шаг0
	ГДЕ
		ДОБАВИТЬКДАТЕ(Период, ДЕНЬ, 1) <= &КонецПериода) КАК Куча

СГРУППИРОВАТЬ ПО
	Номенклатура,
	Период
;
////////конец повторов////////

ВЫБРАТЬ
	Номенклатура,
	Период,
	Было
ИЗ
	ШагХ

УПОРЯДОЧИТЬ ПО
	Номенклатура,
	Период

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

Возможно, кому-то приведенный запрос покажется похожим на  "машину Руби Голдберга" (она изображена на картинке в анонсе). Сходство действительно есть. Тут тоже используется принцип домино. Но вот с точки зрения эффективности все наоборот: приведенный запрос очень экономен. Наилучшим случаем является большая разреженность таблицы остатков. Когда, например, оборот (и остаток) задан в исходной таблице оборотов и остатков  только за один день периода, потребуется ровно N операций для заполнения пропусков на интервале из N дней. В наихудшем случае отсутствия пропусков для работы алгоритма потребуется примерно N/2 * log (N) времени. Оно уйдет на безуспешные попытки распространить остаток на уже "занятые" периоды. 

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

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

Для примера к статье приложен отчет на базе СКД, решающий одновременно задачи нахождения остатков и цен на каждый день. Интересно, что предложенный прием позволяет решать эти задачи одновременно. Отчет проверен на конфигурации 1С:ERP Управление предприятием 2.1, но должен работать и в УТ11 и в КА2.

Специального сравнительного тестирования производительности нового способа и обычных способов в данном случае не проводилось. В других случаях [Быстрое определение интервалов в запросе] похожие подходы начинают выигрывать у традиционных при достаточно больших значениях N. Обычно это сотни и тысячи дат в периоде. Поэтому решающих преимуществ у данного способа перед уже известными на обычных средних объемах данных как будто бы нет.  Кроме своеобразной красоты регулярности итогового запроса.

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

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
Отчет "Остатки и цены на каждый день" для ERP2, КА2, УТ11
.erf 12,34Kb
24.04.16
21
.erf 12,34Kb 21 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Андрей Сябренко (AzagTot) 25.04.16 15:21
Профессор Руби зачетный чел)
2. bulpi bulpi (bulpi) 25.04.16 15:45
Красиво.
Смущают функции Максимум(Было), Максимум(Стало)
Предполагается, что в запросе функция МАКСИМУМ (NULL,1)=1 . А это точно так ?
3. Павел Чистов (GROOVY) 25.04.16 15:57
Меня все смущает. Зачем два раза дергать таблицу? Зачем в текст добавлять таблицы "Повторяется Х раз"?

Достаточно выборку сделать с тета-соединением.
В выборке, конечно, дат с пустыми значениями мы не получим, но и в выборке из результата запроса и в СКД можно добавить пустые значения. А для прямой выгрузки в ТЗ сомнительный механизм, выборка в общем случае будет эффективнее.
4. Сергей (ildarovich) 25.04.16 16:03
(2) bulpi, запрос я протестировал, он работает. Мне кажется такое поведение по отношению к NULL ожидаемым.
Да и вдокументации по T-SQL написано:
При выполнении функции MAX все значения NULL пропускаются.
Кстати, у меня было еще два варианта повторяющегося фрагмента, основанные на соединении. Код получается даже более коротким, но я был не уверен, что планировщик подберет правильный план и поэтому оставил более надежное объединение.
5. Сергей (ildarovich) 25.04.16 16:18
(3) GROOVY,
зачем два раза дергать таблицу
Если вы про начало запроса, то там это делается, чтобы дополнить нулями начальные значения. Иначе в начале интервала будут пропуски. А так вся номенклатура, имеющая ненулевые остатки на периоде, даст строки с нулями в начале периода, чтобы, если с них начался интервал, распространить нули дальше. Но конечно, можно было бы "дергать таблицу один раз", выбрав дополнения нулями уже из выдернутой таблицы, это я не сделал, чтобы сократить эту часть до максимума. Не в ней суть.

Повторяется Х раз написано потому, что на самом деле этот фрагмент нужно повторить в тексте запроса 5 раз для интервала из 32 дней или 10 раз для интервала 1024 дней. Если бы записать запрос как есть со всеми повторами, то он был бы слишком громоздким и плохо обозримым. Это на самом деле громоздкий, но эффективный запрос. Соответствует картинке. С повторяющейся частью.
Кстати, если вы скачаете обработку, то увидите, что в СКД запрос написан также, а разворачивается только перед выполнением.
Я согласен, что заполнять пропуски можно постобработкой результата, этот спор уже был. Но все же есть задачи, где результат заполнения нужен внутри запроса для последующей обработки.
Например, для расчета пени по величине долга. Могу еще привести примеры. И вообще я против того, чтобы вместо решения задачи критиковать саму ее постановку.
Тэта-соединения дают трудоемкость O(NxN), а здесь - O(N) (в лучшем случае). Запросы с тэта-соединениями известны. А это ЕЩЕ ОДИН способ, "красивый".
swiss-garant; IgorS; Serj1C; Программулькин; +4 Ответить
6. Иван Петров (dgolovanov) 25.04.16 22:50
Много статей читаю на ИС, в т.ч. уважаемого ildarovich. Непременно в каждой найдется некто с вопросом "а нахрена это?", "сделай в СКД встроенными функциями" и вершина знаний - тэта-соединение с его чудовищной неэффективностью. Это не камень в сторону уважаемого GROOVY, которому я очень благодарен за пройденные курсы. Но тенденция явная. А потом обижаемся на анекдоты типа "На паралимпиаду по программированию приглашаются программисты на 1С, РНР и VBA".
kare; swiss-garant; Perrojka; cleaner_it; IgorS; +5 Ответить
7. Руслан (lrs) 26.04.16 09:59
В целом идея очевидная, распространять остаток предыдущего дня на следующий. Фишка в последовательности 1,2,4,8,16.... позволяющая на порядок сократить циклы обработки данных! До этого конечно не каждый додумается))
8. Сергей (ildarovich) 26.04.16 11:12
+(4) Вот еще один вариант повторяющегося фрагмента c использованием Left Anti Semi Join. Он несколько понятнее и короче, но не уверен, что на всех СУБД будет использован правильный план запроса:
ВЫБРАТЬ
	Шаг.Период,
	Шаг.Было
ПОМЕСТИТЬ Шаг1
ИЗ
	Шаг0 КАК Шаг //таблица, полученная на предыдущем шаге

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
	ДОБАВИТЬКДАТЕ(Шаг.Период, ДЕНЬ, 1), //1, 2, 4, 8, 16 и так далее
	Шаг.Было
ИЗ
	Шаг0 КАК Шаг
		ЛЕВОЕ СОЕДИНЕНИЕ Шаг0 КАК Табу
		ПО (ДОБАВИТЬКДАТЕ(Шаг.Период, ДЕНЬ, 1) = Табу.Период)
ГДЕ
	ДОБАВИТЬКДАТЕ(Шаг.Период, ДЕНЬ, 1) <= &КонецПериода
	И Табу.Период ЕСТЬ NULL
...Показать Скрыть
9. Василий Казьмин (awk) 26.04.16 15:07
Если текст запроса динамический, то почему не использовать такой объект как "Схема запроса"?
10. Сергей (ildarovich) 26.04.16 15:55
(9) awk, думал над этим, но так (по-старинке) кода получается существенно меньше.
Четыре СтрЗаменить:
1) Шаг0 -> ШагХ-1; 2) Шаг1->ШагХ;(в повторе) 3) &Шаг -> Х; 4) Шаг1->ШагХ (в эпилоге).
Причем первые три одной строкой.
Вот, собственно, код:
ТекстЗапроса = СхемаКомпоновкиДанных.НаборыДанных.НаборДанных1.Запрос;
	Секции = ЧастиТекста(ТекстЗапроса, ";");
	ТекстЗапроса = Секции[0] + ";"; //исходная выборка
	НомерТура = 0; 
	Охват = 1;
	Пока Охват * 86400 <= КонецПериода - НачалоПериода Цикл
		ТекстЗапроса = ТекстЗапроса	+ СтрЗаменить(СтрЗаменить(СтрЗаменить(Секции[1]
		, "Шаг1", "Шаг" + (НомерТура + 1)), "Шаг0", "Шаг" + НомерТура), "&Шаг", Охват) + ";";
		НомерТура = НомерТура + 1;
		Охват = 2 * Охват
	КонецЦикла;
	ТекстЗапроса = ТекстЗапроса + СтрЗаменить(Секции[2], "Шаг1", "Шаг" + НомерТура); //итоговая выборка
	СхемаКомпоновкиДанных.НаборыДанных.НаборДанных1.Запрос = ТекстЗапроса;
...Показать Скрыть
Но вообще попробовать можно...
11. Андрей Гореликов (alon) 27.04.16 09:49
Я так понимаю, что на начало периода в регистре не должно быть отрицательных остатков. Иначе ноль перебьет реальное значение в функции максимум.
Ovrfox; ildarovich; +2 Ответить 1
12. Сергей (ildarovich) 27.04.16 10:19
(11) alon, вы совершенно правы, упустил этот момент. Для остатков агрегатная функция могла быть суммой. А для регистров сведений - максимумом. Когда решил не писать два разных варианта, про необходимость входной группировки по сумме в случае остатков не вспомнил.
Чуть позже уточню запросы в статье и в обработке.
Спасибо за вашу внимательность.
13. Василий Казьмин (awk) 27.04.16 14:12
(10) ildarovich, Я про объект конфигурации "Схема запроса", а не про СКД.
14. Сергей (ildarovich) 27.04.16 15:31
(13) awk, да понял я, понял. Про это и отвечал. Хотя и сомневаюсь, что выйдет короче, чем в (10), но попробую для интереса применить для распаковки код типа
СхемаЗапроса = Новый СхемаЗапроса;
СхемаЗапроса.УстановитьТекстЗапроса(Запрос.Текст);
...
Запрос.Текст = СхемаЗапроса.ПолучитьТекстЗапроса();
Но вообще-то прямого отношения к обсуждаемому решению это не имеет.
15. Олег Родионов (Ovrfox) 28.04.16 11:16
Ребята, почему никто из Вас не подумал над применимостью данного запроса. Он вообще никому не нужен!
Если данные сильно разреженные и остатки считаются за несколько милисекунд, то кто вообще будет оптимизировать запрос? Тем более под специально разреженные данные? Ведь и так все быстро работает.
Если сравнить данный метод с любым другим, который выбирает остатки из бд один раз, а потом распространяет их любым способом, без обращения к перерасчету остатков, то что мы получим?
Худший метод замедлит выдачу максимум на пару секунд, если кто-то додумается выбрать остатки второй раз с помощью конструкции "ОстаткиИОбороты" то такое обращение на более - менее больших БД замедлит выдачу рещультата значительно, в большинстве случаев вдвое. Т.к. для меня "Большие БД" это те, где подобная конструкция "ОстаткиИОбороты" считается значительный промежуток времени (пару секунд) и ты начинаешь оптимизировать отчеты, избегая данной конструкции.
Итого - как красивое, хоть и абсолютно бесполезное , данное решение имеет право на жизнь. В теоретических книгах. Но на практике 100% не применимо.
16. Сергей (ildarovich) 28.04.16 12:26
(15) Ovrfox, готов с вами поспорить. Хотя не все понял в ваших рассуждениях. А вы все поняли в моих? -Давайте попробуем понять друг друга!
Итак, с чем я спорю:
Он (способ) вообще никому не нужен! ... на практике 100% не применимо
Я спорю по поводу 100%. Могу согласиться "на практике 90% не применимо", "на практике 95% не применимо" и тому подобное. Вот для этих 5-10% случаев способ применим, поэтому лучше о нем знать, чем не знать.

Теперь, что я не понял: вы считаете, что способ выбирает ОстаткиИОбороты принципиально два раза? - но это совсем не так. Исходную таблицу для работы метода можно получить любым способом, каким быстрее:
1) объединив остатки на начало периода (решив вопрос с нулевыми) и остатки на дни с оборотами внутри периода;
2) сделав выборку остатков внутри периода и выбрать дополнения нулями из нее;
3) объединив номенклатуру, имеющую обороты, выбранную из остатков и оборотов и остатки внутри периода (как сделано у меня).
Не думаю, что между этими способами есть принципиальная разница по скорости - порядок цифр один и тот же.

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

Не понял какое ускорение вы считаете существенным: две секунды уже хорошо? То есть мне для доказательства практичности нужно найти случаи с выигрышем более двух секунд?

А поняли ли вы, что подобный прием работает и для регистров сведений, где и разреженность чаще встречается и "остатки и обороты" (роль этой таблицы играет физическая таблица регистра сведений) вообще никак не обойти?

Суть приема в том, чтобы не искать для каждой даты ближайшую нужную в прошлом, что сопряжено с затратами, а переносить известное значение на нужное расстояние вперед уже без поиска.
17. Сергей (ildarovich) 30.04.16 14:43
+ (16) Замечание в (15) заставило повнимательнее отнестись к анализу эффективности предложенного метода. Дополнительные исследования показали, что:

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

2) Трудоемкость классики описывается формулой O(M x N), где N - величина интервала в днях, а М - число дней с оборотами. А трудоемкость домино приближенно описывается формулой O(M x Log(M) + N - M). Выигрыш домино у классики возрастает по мере увеличения плотности исходной таблицы. Примерно на 70% заполнения достигает максимума, а затем немного уменьшается;

3) Величина выигрыша может достигать очень больших значений: многие десятки раз!

Для примера был посчитан курс валют на каждый день с 1.01.2009 для 4096 дней. Классика выполняет запрос 9,36 секунд, а домино - 0,375 секунды (файловая база УТ10.3). То есть ускорение в 25 раз! На девять секунд! И это по одной валюте!
Текст этого тестового запроса приведен далее. В нем четыре параметра: НачалоПериода, Валюта, ЧислоДнейДомино, ЧислоДнейКлассика. Если оба числа дней равны, методы работают вместе и их результаты сравниваются. Обнуляя соответствующее число дней, можно увидеть чистое время работы метода-конкурента.
Запрос будет работать в любой базе, имеющей регистр сведений КурсыВалюты.

////запрос классика
ВЫБРАТЬ 0 КАК Х ПОМЕСТИТЬ Ч2 ОБЪЕДИНИТЬ ВЫБРАТЬ 1;
ВЫБРАТЬ А.Х + 2 * Б.Х КАК Х ПОМЕСТИТЬ Ч4 ИЗ Ч2 КАК А, Ч2 КАК Б;
ВЫБРАТЬ А.Х + 4 * Б.Х КАК Х ПОМЕСТИТЬ Ч16 ИЗ Ч4 КАК А, Ч4 КАК Б;
ВЫБРАТЬ А.Х + 16 * Б.Х КАК Х ПОМЕСТИТЬ Ч256 ИЗ Ч16 КАК А, Ч16 КАК Б;
ВЫБРАТЬ А.Х + 256 * Б.Х КАК Х ПОМЕСТИТЬ Ч4096 ИЗ Ч256 КАК А, Ч16 КАК Б;
ВЫБРАТЬ ДОБАВИТЬКДАТЕ(&НачалоПериода, ДЕНЬ, Х) КАК Х ПОМЕСТИТЬ Даты ИЗ Ч4096 ГДЕ Х < &ДнейПериодаКлассика;

ВЫБРАТЬ Х, МАКСИМУМ(Период) КАК Дата ПОМЕСТИТЬ ДатыКурса 
ИЗ Даты ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.КурсыВалют ПО Валюта = &Валюта И &НачалоПериода <= Период И Период <= Х 
СГРУППИРОВАТЬ ПО Х;

ВЫБРАТЬ Х, Курс ПОМЕСТИТЬ КурсыКлассика 
ИЗ ДатыКурса ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.КурсыВалют ПО Дата = Период И Валюта = &Валюта;
////запрос домино
ВЫБРАТЬ 0 КАК Х, NULL КАК Было ПОМЕСТИТЬ Шаг0 
ОБЪЕДИНИТЬ 
ВЫБРАТЬ РАЗНОСТЬДАТ(&НачалоПериода, Период, ДЕНЬ), Курс ИЗ РегистрСведений.КурсыВалют 
ГДЕ Валюта = &Валюта И &НачалоПериода <= Период И РАЗНОСТЬДАТ(&НачалоПериода, Период, ДЕНЬ) < &ДнейПериодаДомино;

ВЫБРАТЬ Х, Было, NULL КАК Стало ПОМЕСТИТЬ Шаг1 Из Шаг0 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Х + 1, NULL, Было Из Шаг0 ГДЕ Х + 1 < &ДнейПериодаДомино; 
УНИЧТОЖИТЬ Шаг0;
ВЫБРАТЬ Х, ЕСТЬNULL(МАКСИМУМ(Было), МАКСИМУМ(Стало)) КАК Было ПОМЕСТИТЬ Шаг0 Из Шаг1 СГРУППИРОВАТЬ ПО Х; 
УНИЧТОЖИТЬ Шаг1;

ВЫБРАТЬ Х, Было, NULL КАК Стало ПОМЕСТИТЬ Шаг1 Из Шаг0 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Х + 2, NULL, Было Из Шаг0 ГДЕ Х + 2 < &ДнейПериодаДомино; 
УНИЧТОЖИТЬ Шаг0;
ВЫБРАТЬ Х, ЕСТЬNULL(МАКСИМУМ(Было), МАКСИМУМ(Стало)) КАК Было ПОМЕСТИТЬ Шаг0 Из Шаг1 СГРУППИРОВАТЬ ПО Х; 
УНИЧТОЖИТЬ Шаг1;

ВЫБРАТЬ Х, Было, NULL КАК Стало ПОМЕСТИТЬ Шаг1 Из Шаг0 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Х + 4, NULL, Было Из Шаг0 ГДЕ Х + 4 < &ДнейПериодаДомино; 
УНИЧТОЖИТЬ Шаг0;
ВЫБРАТЬ Х, ЕСТЬNULL(МАКСИМУМ(Было), МАКСИМУМ(Стало)) КАК Было ПОМЕСТИТЬ Шаг0 Из Шаг1 СГРУППИРОВАТЬ ПО Х; 
УНИЧТОЖИТЬ Шаг1;

ВЫБРАТЬ Х, Было, NULL КАК Стало ПОМЕСТИТЬ Шаг1 Из Шаг0 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Х + 8, NULL, Было Из Шаг0 ГДЕ Х + 8 < &ДнейПериодаДомино; 
УНИЧТОЖИТЬ Шаг0;
ВЫБРАТЬ Х, ЕСТЬNULL(МАКСИМУМ(Было), МАКСИМУМ(Стало)) КАК Было ПОМЕСТИТЬ Шаг0 Из Шаг1 СГРУППИРОВАТЬ ПО Х; 
УНИЧТОЖИТЬ Шаг1;

ВЫБРАТЬ Х, Было, NULL КАК Стало ПОМЕСТИТЬ Шаг1 Из Шаг0 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Х + 16, NULL, Было Из Шаг0 ГДЕ Х + 16 < &ДнейПериодаДомино; 
УНИЧТОЖИТЬ Шаг0;
ВЫБРАТЬ Х, ЕСТЬNULL(МАКСИМУМ(Было), МАКСИМУМ(Стало)) КАК Было ПОМЕСТИТЬ Шаг0 Из Шаг1 СГРУППИРОВАТЬ ПО Х; 
УНИЧТОЖИТЬ Шаг1;

ВЫБРАТЬ Х, Было, NULL КАК Стало ПОМЕСТИТЬ Шаг1 Из Шаг0 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Х + 32, NULL, Было Из Шаг0 ГДЕ Х + 32 < &ДнейПериодаДомино; 
УНИЧТОЖИТЬ Шаг0;
ВЫБРАТЬ Х, ЕСТЬNULL(МАКСИМУМ(Было), МАКСИМУМ(Стало)) КАК Было ПОМЕСТИТЬ Шаг0 Из Шаг1 СГРУППИРОВАТЬ ПО Х; 
УНИЧТОЖИТЬ Шаг1;

ВЫБРАТЬ Х, Было, NULL КАК Стало ПОМЕСТИТЬ Шаг1 Из Шаг0 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Х + 64, NULL, Было Из Шаг0 ГДЕ Х + 64 < &ДнейПериодаДомино; 
УНИЧТОЖИТЬ Шаг0;
ВЫБРАТЬ Х, ЕСТЬNULL(МАКСИМУМ(Было), МАКСИМУМ(Стало)) КАК Было ПОМЕСТИТЬ Шаг0 Из Шаг1 СГРУППИРОВАТЬ ПО Х; 
УНИЧТОЖИТЬ Шаг1;

ВЫБРАТЬ Х, Было, NULL КАК Стало ПОМЕСТИТЬ Шаг1 Из Шаг0 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Х + 128, NULL, Было Из Шаг0 ГДЕ Х + 128 < &ДнейПериодаДомино; 
УНИЧТОЖИТЬ Шаг0;
ВЫБРАТЬ Х, ЕСТЬNULL(МАКСИМУМ(Было), МАКСИМУМ(Стало)) КАК Было ПОМЕСТИТЬ Шаг0 Из Шаг1 СГРУППИРОВАТЬ ПО Х; 
УНИЧТОЖИТЬ Шаг1;

ВЫБРАТЬ Х, Было, NULL КАК Стало ПОМЕСТИТЬ Шаг1 Из Шаг0 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Х + 256, NULL, Было Из Шаг0 ГДЕ Х + 256 < &ДнейПериодаДомино; 
УНИЧТОЖИТЬ Шаг0;
ВЫБРАТЬ Х, ЕСТЬNULL(МАКСИМУМ(Было), МАКСИМУМ(Стало)) КАК Было ПОМЕСТИТЬ Шаг0 Из Шаг1 СГРУППИРОВАТЬ ПО Х; 
УНИЧТОЖИТЬ Шаг1;

ВЫБРАТЬ Х, Было, NULL КАК Стало ПОМЕСТИТЬ Шаг1 Из Шаг0 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Х + 512, NULL, Было Из Шаг0 ГДЕ Х + 512 < &ДнейПериодаДомино; 
УНИЧТОЖИТЬ Шаг0;
ВЫБРАТЬ Х, ЕСТЬNULL(МАКСИМУМ(Было), МАКСИМУМ(Стало)) КАК Было ПОМЕСТИТЬ Шаг0 Из Шаг1 СГРУППИРОВАТЬ ПО Х; 
УНИЧТОЖИТЬ Шаг1;

ВЫБРАТЬ Х, Было, NULL КАК Стало ПОМЕСТИТЬ Шаг1 Из Шаг0 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Х + 1024, NULL, Было Из Шаг0 ГДЕ Х + 1024 < &ДнейПериодаДомино; 
УНИЧТОЖИТЬ Шаг0;
ВЫБРАТЬ Х, ЕСТЬNULL(МАКСИМУМ(Было), МАКСИМУМ(Стало)) КАК Было ПОМЕСТИТЬ Шаг0 Из Шаг1 СГРУППИРОВАТЬ ПО Х; 
УНИЧТОЖИТЬ Шаг1;

ВЫБРАТЬ Х, Было, NULL КАК Стало ПОМЕСТИТЬ Шаг1 Из Шаг0 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Х + 2048, NULL, Было Из Шаг0 ГДЕ Х + 2048 < &ДнейПериодаДомино; 
УНИЧТОЖИТЬ Шаг0;
ВЫБРАТЬ Х, ЕСТЬNULL(МАКСИМУМ(Было), МАКСИМУМ(Стало)) КАК Было ПОМЕСТИТЬ Шаг0 Из Шаг1 СГРУППИРОВАТЬ ПО Х; 
УНИЧТОЖИТЬ Шаг1;

ВЫБРАТЬ ДОБАВИТЬКДАТЕ(&НачалоПериода, ДЕНЬ, Х) КАК Х, Было КАК Курс ПОМЕСТИТЬ КурсыДомино Из Шаг0;
////сравнение результатов
ВЫБРАТЬ Х, Курс, СУММА(Ошибка)
ПОМЕСТИТЬ Ошибки 
ИЗ (ВЫБРАТЬ Х, Курс, -1 КАК Ошибка ИЗ КурсыКлассика ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ Х, Курс, 1 ИЗ КурсыДомино) КАК Куча
СГРУППИРОВАТЬ ПО Х, Курс
ИМЕЮЩИЕ СУММА(Ошибка) <> 0
...Показать Скрыть


Для другого теста была посчитано изменение по дням широты ассортимента (количество различных товаров с ненулевыми остатками). Так вот, если товар на интервале полтора года (500 дней) двигался более 50 раз (в тестовой базе было порядка сотни таких товаров), то расчет по домино ускорялся в три раза: с 30 до 10 секунд.

Чуть позже дополню всей этой информацией статью.

Еще раз подчеркну: метод во многих случаях чрезвычайно эффективен!
Evil Beaver; awk; +2 Ответить
18. Two World (Prometeus2011) 25.05.16 16:48
Попросили обработку написать для вычисления штрафов работникам по упущенной выгоде. Чтоб было вообще ФАААЯЯЯЯ, решил применить способ Сергея.
В процессе применения выяснилось, что придется посчитать двоичный логарифм средствами 1с, т.к. "Для заполнения интервала из 32 дней достаточно пятикратного , а для интервала из 1024 дней - десятикратного повторения ключевого фрагмента".
Навскидку не нашел в 1с функции вычисления двоичного логарифма (Двоичный логарифм - степень, в которую нужно возвести число 2, чтобы получилось заданное число).

Написал маленький кусочек кода для его вычисления:

КолДней = 31;  //Дни, за которые необходимо остатки посчитать (32, 1024 ...)
КолИтераций = 0;
Рез = 1;
Пока Рез<КолДней цикл
	КолИтераций = КолИтераций + 1;
	РЕз = Рез*2;
	Если РЕз>КолДней тогда
		ПРервать;
	КонецЕсли;
КонецЦикла;
//КолИтераций  - Количество повторений среднего участка запроса.
...Показать Скрыть
19. Олег Родионов (Ovrfox) 21.06.16 18:11
(18) Prometeus2011,
А зачем?
При формировании запроса в цикле
МаксДней = 1;
Пока МаксДней <= РазницаДат Цикл
ТекстЗапроса = ТекстЗапроса + //Запрос цикла для максДней
МаксДней = МаксДней*2;
КонецЦикла;
Таким образом не нужно считать заранее к-во шагов для удвоения дат.
20. Вячеслав Голев (ra-it) 08.07.16 15:06
Использовали похожий метод для поиска дебиторских документов по фифо (в соседней ветке где-то видел описание). Работает сильно быстрее (много документов). Но нужно иметь ввиду особенность СКД, если ей скармливать полностью запрос (у нас запрос вышел 9600 строк) - при некоторых настройках группировок СКД считает, что "раз эти поля не используются в выводе, то соптимизирую-ка я такой большой запрос, и не буду выполнять ненужные пакеты". В итоге получаем искаженные данные. Пришлось ставить признак "Обязательное" для всех полей компоновки, дабы пресечь волюнтаризм платформы и получить корректный результат :)
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа