Регистры накопления 1С как технология

В бюджетной базе появилась куча новых таблиц. Я решила, что это аналоги регистров с суммами появились и раскатала губу. Пришлось закатать обратно потому что это не они.
При некоторых размерах базы (достаточно больших) обычных SQL –строк недостаточно. Они работают, но очень медленно. Потому целесообразно заводить таблицы с формально избыточной информацией, предназначенные для ускорения суммирования. 1С-овцы просто с этим раньше столкнулись и потому придумали специальный инструментарий. Я с этим столкнулась когда офисная база за 10 лет начла медленно суммировать. Работать с отдельными базами по годам неудобно (остатки, например, на начало года переносить надо) потому в офисе категорически потребовали одну общую базу от начала её ведения. Так и я столкнулась с объемами, которые требуют таких надстроек над данными. Бюджетная база большая хоть и за один год. По-моему она вполне достойна такой надстройки.
Объяснюсь в чём дело. Исполнение бюджета это разность плана и платёжек. Чтобы получить эту сумму мне надо просуммировать все передвижки (это будет план) и вычесть из этого сумму по всем платёжкам (это будет факт). Корректировок плана (строк в таблицах) ещё не очень много. А платежек много. Когда мне нужна сумма я пишу:

ВЫБРАТЬ СУММА(Оплата) ИЗ ТаблицаПлатёжек ГДЕ Учреждение=То, которое интересует.
Машина берёт сортировку (индекс) по учреждениям, находит первую строку по интересующему учреждению и дальше суммирует все строки пока не кончится информация по этому учреждению.
Если мне нужна сумма по распорядителю, то машина будет ползти по всей базе  суммировать все платёжки по учреждениям распорядителя. И так каждый раз, когда эта информация кому-то потребовалась. Так можно но это и долго и нагрузка на технику. Долго, в числе прочего потому, что куча народу таким способом нагружает сервер.
Покажу вначале, как это решается в 1С просто потому что там есть картинки с результатом. Есть у меня простенькая база, на которой легко такие вещи показывать:
В 1С кроме справочников (классификаторы типа K_CS – классификатор целевых документов), документов (типа расходных платёжек ZF_R), есть так называемые регистры:

Бухгалтерский это для работы с бухгалтерскими счетами. Но иногда надо что-то суммировать что выходит за рамки бухгалтерии. Для этих случаев существуют регистры накопления. Если смотреть со стороны 1С, то это просто таблица, в которую записывается информация каждого сохраняемого документа. В случае бюджетных платёжек это было бы с виду простое дублирование информации, но предлагается реализовать идею а не сделать также как сделано в 1С.
В примере у меня есть приходный и расходный документ («Закупка» и «Списание») и резистор (»ЗакупкаОборотыОстатки»):

В регистре у меня есть кроме обычных для бухгалтерии счетов и суммы ещё товар и количество. Т.е регистр нужен чтобы быстро получать оборотку в разрезе товаров (не только счетов) и считать ещё и килограммы какие-нибудь (которых нет в балансе).
При проведении (можно считать, что при сохранении) документа выполняется такой текст:

Т.е в регистр добавляется информация по записываемому документу с типом строк «Приход». Для документа «Списание» вид движения будет «Расход». В бюджетной базе естественнее всё это делать триггерами а не из Access-а.
Написанный текст прост, но на самом деле внутри делается нечто довольно хитрое, позволяющее собирать оборотку по такой информации (конструктор отчёта):

Мало того, что формально один регистр внутри расползается на 4 таблицы. Ещё у него есть возможность выбирать все мыслимые диапазоны периодов:

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