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

P.S. В этой схеме как можно заметить нет учета сторно и срез обьединяет в себе все начисления услуг, которые имеют постоянный обьем потребления. При желании можно доработать в нужную сторону, я как бы привел облегченную модель.

P.S. Аналогичную модель можно применять к разным задачам. Например у меня таким образом в "Расчете зп" организована модель хранения учета табельного времени - есть план (график работ), есть факт (отклонения и дополнения от графика). Зачем спрашивается хранить на 20 рабочих дней учет табельного времени на сотрудника, если у него не было отклонения от плана и он честно отработал 20 дней. Для одного сотрудника может и не критично, а вот для 1000 для 3-летней базы даже очень существенно будет по обьему таблички :)

Насчет рассылки больной вопрос - времени полный ноль. Скорее всего я ее скоро запущу вновь в обрезанном варианте - Новости от Sybase.com, Sybase.ru и буду в ней давать ссылки по решениям, выложенным в FAQ, чтобы не разрываться между FAQ и рассылкой. В тему сказать, на руках имеются пара красивых и универсальных решений (как мне кажется) для ASA9 по моделям хранения информации за периоды и задним числом (в том числе есть ХП, самостоятельно генерящие на таблицы по таким моделям триггера, которые полностью обеспечивают работоспособность моделей). Осталось только выделить кусок времени и перенести эти решения в FAQ. Ориентировочно думаю это произойдет после 7-ого августа (моя семья едет в отпуск и 2 недели мне все равно будет особо нечего дома по вечерам делать) :)

авторА вот для постоянного объема потребления... я еще проверю на опыте, но мне кажется что в моем случае будет дороже проверять неизменность параметров, чем рассчитать еще раз.
Согласен, зависит от обьемов данных, частоты их изменения и насколько в БД реальна возможность при изменение входящих данных определять, на что они могут влиять. Например, если расширить Ваш "Кэш неготовности" еще полем признаком: "Необходимость пересчета услуг с постоянным потреблением", то по идее при расчете если он выставлен, организуется новый срез начислений, иначе дается просто ссылка на последний существующий.

P.S. Важное замечание - все это выгодно использовать, если расчеты проводяться запросами по множеству лицевых счетов. Если расчеты ведутся единично по каждому лицевому счету их перебором, то я не уверен, что мои советы чем то могут помочь, вполне возможно наоборот замедление расчетов.

авторЭ-э. Не забывайте, что комуналка - не начисление зарплаты. Данные о платежах вводятся по мере поступления документов. На вводе данных сидит не более 20 теток. Нет проблем пересчитать ВСЕ данные по лицевому счету при подтверждениии ввода очередных показателей. Сервак справится.
Так обсуждаем не платежи (оплату), а выставление начислений. Крупный ДЭЗ можем иметь до 50 000 лицевых счетов и десятки рассчитываемых услуг. Почти все из них имеют постоянный обьем потребления (в основном потребление воды динамически меняется в зависимости от показания счетчика). Каждый месяц нужно выставлять этим лицевым счетам начисления (производить расчет), т.е. даже если в среднем лицевой счет имеет 5 услуг, то за месяц на 50 000 счетов это 250 000 записей начислений. Далее возникает интересный вопрос изменения входящей информации задним числом (например на полгода назад изменился тариф) и мы имеем необходимость пересчета 6 месяцев всех лицевых счетов, у которого задействована услуга с изменившемся тарифом. Причем например, в Москве всю оплату и разбивку по начислениям делает банк Москвы, который тоже вносит свою достойную лепту в хаос автоматизации коммуналки, не учитывает переоплату, криво опознает сторно и т.д.

Одно ясно, коммуналка это гнев божий, слава богу я с зп вожусь, там хоть ТК не так часто меняется и если выбросить из внимания мутотень с инвалидами в ЕСН, то все не так уж и плохо :)