Накопительный итог 1С #531923

Здравствуйте. Стоит задача получить лесенку (накопительный итог) по последовательности документов. Поясню напримере - есть исходная таблица произвольных документов:   Нужна таблица: РТиУ №01    100    880 РТиУ №02    500    780 РТиУ №03    80    280 РТиУ №04    200    200 Какой самый быстрый способ ее получить? Сейчас используется конструкция: Но для большого количества документов работает дико медленно. Собственно вопрос каким  запросом можно получить тот – же результат за меньшее время?

выбрать в ТЗ, пробежаться посчитать?

ТЗ обработать?

самый быстрый - правильно использовать регистры

Запрос состоит из множества пакетов (этот один из промежуточных).

ты бы хотть так написал бы : РТиУ №01    200    200 РТиУ №02     80    280 РТиУ №03    500    780 РТиУ №04    100    880

мне нужно так как написано в . хотя это не принцыпиально.

индексы по моментвремени+суммаупр попробовать

по моменту времени нет индексации.

Рг накопления прикрутить уже поздно ?

да

та же 25 Гбайт мясная база ?

условия сделать на дату + ссылку и по ним индексы

нет 150 Гб (наш филиальчеГ) :))

Чем регистр накопления поможет?

попробывал, не канает...

чем не канает?

а если сделать так для печатной формы

быстрее не стало работать.

результат запроса в не конечный он еще многократно обрабатывается.

что ещё ?

Навскидку:

то же самое...

Что то же? Ты хоть почитай. Условие как у тебя. Решение там - пост 10.

предлагаешь курсор сделать ?

тот же коннект ПериодыИзменения.Период >= Регистр.Период что нового я там должен увидить?

чево за курсор как по одноэсовски будет?

и какой же индекс был использован?

А что ты хочешь увидЕть? Если решение - то оно там. Что ещё?

Да, в самом деле... Извини. Мож в комментах что полезное.

ИНДЕКСИРОВАТЬ ПО    Регистратор,    СуммаУпр -только не понятно как этот индекс может ускорить соединение по МоментВремени.

+ Мда... Ничего применимого к 1С в комментах не нашел. Все более быстрые способы к 1С не применимы.

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

[как по одноэсовски будет] ни как отдаленный аналог курсора - временная таблица, её ты уже использовал

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

дык вариант с накоплением итога по регистратору в Рг накопления ты отверг

как мне его накопить? допустим есть пары Договор+Контрагент один пользователь захочет посмотреть в разрезе одного договора другой в разрезе всех.... у меня нет четкого соответствия Регистратор-Накопительный итог.

Договор+Контрагент=Договор+регистратор сори...

Судя по всему, на голом SELECTе быстрее никак. В T-SQL более быстрые варианты реализуют курсорами и DML.

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

40 тыс. документов "на входе".

и сколько отрабатывает по времени? и если "на входе" будет 1000 доков, скока будет отрабатывать?

800млн строк обработать - не шухры мухры =)

минут 10-20 не замерял точно.

в таблице 890 строк запрос отработал 1,4с        "ВЫБРАТЬ ПЕРВЫЕ 200        "ВЫБРАТЬ ПЕРВЫЕ 200 отработал за 0.6сек на количестве данных 40000 будет еще существеннее. за минутку может и отработать.. быстрее хз как =)

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

вопрос не в искомом, а в скорости получения искомого.

Вопрос, как поведет себя такая методика на многомиллионных таблицах в сравнении с обычным методом. Сравни, плиз, с шагом в лимонов 5 строк несколько замеров. У тебя ведь всё готово уже. Очень интересно тенденцию отследить. Насколько замедлит работу многократное переливание туда-сюда огромной исходной таблицы (с выкусыванием обработанных порций). Ведь замедление этой операции замедляет работу всего алгоритма в геометрической прогрессии. Хочется понять, насколько метод применим на больших таблицах. Кстати, ЛЕВОЕ СОЕДИНЕНИЕ ПО ИСТИНА можно заменить на стандартную запись декартова произведения в SQL - просто указав вторую таблицу через запятую без всяких соединений. А Не ВыборкаПроверка.Следующий на Запрос.Выполнить.Пустой

если будет 1млн строк, то присоединение из даст обработку в 500 трл строк. сервер сдохнет.. а на счет "Пустой" тоже можно =)

Вот не факт, что сдохнет. Тут практика важнее домыслов.

ошибся, в 500блн строк

у сервера стока оперативки нетю..

не, трл =) чета засчитался. ща проверю на более больших данных

ЗЫ на млн строк даж пробовать не буду =) сами пробуйте если хотите.

Ну, можно на меньших объемах. Главное хоть какой-то тренд наметить.

скульсервак (база на скуле, новые тесты). до этого была файловая база проверка на 1000 строк одним запросом: 0.55сек обработкой по 200 строк: 0.77сек обработкой по 500 строк: 1.3сек проверка на 16 000 строк одним запросом: 82сек обработкой по 200 строк: 17сек обработкой по 500 строк: 12.7сек обработкой по 1000 строк: 13.1сек

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

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

да много чего можно было бы.. только запросы в 1с только те что T-SQL. а курсоры - это дело каждой СУБДшки.. поэтому и не делают

+ Но всё равно будет быстрее твоего варианта, хотя и сложнее...

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

+ ну и следующий скуль обещают наваять.. в 10ке.. хотя бета уже есть, можно глянуть. но на 1с это не отразится =)

T-SQL это как раз курсоры :) Это название диалекта MSSQL. Речь не о курсорах, их понятно почему нет. Речь о возможности INSERTов во временные таблицы. Это кучу бы возможностей дало.

T-SQL - транзактСКЛ, стандарт собственно говоря,которая каждая СУБДшка должна поддерживать =)