2 AlexUnik. Ты затронул весьма непростую и интересную тему. Безболезненно и идеально эта проблема не решается никак. Есть какие-то "консенсусы", которые могут устраивать в той или иной ситуации, но универсального решения просто не существует. Я приведу выдержку из своей статьи двухлетней давности, лежащей тут http://nsa.chat.ru/Raznoe_About.html:
....
Очевидно, что объем регистра может очень быстро расти. Типичная проблема - как достаточно быстро получить остатки по регистру на любую учетную дату, если отражается в нем только движение? Обычно регистр дробится на отрезки определенной протяженности, между которыми фиксируются промежуточные значения остатков. Фиксировать остатки после КАЖДОГО движения не рационально - слишком много в регистре будет информации, которую можно получить расчетным путем, и слишком велико потребление вычислительных ресурсов на пересчет всех остатков при проведении операций "задним числом". Однако, завязывать систему на операции "закрытия учетного периода" тоже некрасиво. В крупной системе пользователи должны иметь возможность вполне нормально работать в разных учетных периодах без каких-либо взаимных помех. Я предпочитаю, чтобы промежуточные остатки по регистру вообще не привязывались к учетному периоду. В своем проекте я привязываю их к критическому количеству прошедших по регистру движений. К примеру, промежуточные остатки могут подсчитываться после каждых 100 движений регистра с одинаковыми аналитическими признаками. В этом случае регистр сам сохранит несколько промежуточных значений остатков даже на протяжении одного дня, если по регистру "товары" за 1 день произошло около 300 движений одной номенклатуры на одном и том же складе. И в то же время по регистру "Ценные бумаги" может несколько кварталов учетного времени вообще не подсчитываться промежуточный остаток, если по этому регистру осуществляются единичные движения. Для получения остатков на запрошенную пользователем дату система извлекает из регистра ближайший к запрошенной дате промежуточный остаток (хранящийся в регистре), добавляет приход и вычитает расход за период до запрошенной даты и расчетным путем получает остаток на запрошенную дату. Технология расчета промежуточных остатков через 100 записей гарантирует, что при этом будет просмотрено не более 100 записей, и время ответа системы будет приемлемым.
....
К сказанному добавлю, что с момента написания статьи у меня взгляды на проблему несколько изменились. Расчет текущих остатков при плавающей границе веьма непрост и сам по себе требует существенных ресурсов. Я пришел к выводу, что наиболее оптимально иметь набор фиксированных интервалов и статистику. Например, остатки могут дробиться: по дням, по неделям, по месяцам, по кварталам, по годам. Конкретный интервал дробления выбирается по статистике оборотов с тем, чтобы между двумя соседними остатками оборотов было, скажем не больше 1000. Можно написать скрипты, которые по ночам или по выходным будут оптимизировать структуру хранения остатков.

2 Глеб. Это действительно очень сложная проблема. Если существует понятие "закрытие учетного периода", то это действительно решает проблемы бустродействия. НО! Это добавляет проблем, если нужно внести изменения в тот период, который закрыт. У нас, к примеру, закрывать вообще нельзя никакие периоды, такова специфика.
Получение остатков не сводится к простому суммированию приходов и вычетанию из них расходов. Представьте, что регистр учета товара ведется по множеству разрезов:
- По филиалам
- По складам
- По кладовщикам
- По номенклатуре
- По номеру приходной партии
... и т.д.
Остатки можно хранить с разблюдовкой по всем аналитикам, а на вопрос "сколько у нас такого-то товара на всех складах?" получать агрегированием остатков по всем остальным аналитикам. Но если аналитических разрезов много, и на каждом из них много значений аналитик, то ответ на поставленный вопрос может занять довольно много времени. Подобные проблемы решаются в системах аналитической обработки (OLAP). В кубах данных сохраняются все комбинации промежуточных остатков, включая самые свернутые и самые развернутые. При этом процесс расчета всех комбинаций промежуточных агрегатов - весьма долгая процедура. OLAP - это системы разлядывания мертвеца - они очень инертны. В данном случае речь идет об OLTP, но с одновременным решением задач, которыми обычно занимаются OLAP. В этом-то и проблема. Вариант с динамическим подрасчетом - весьма напоминиает схему работы с OLAP, и в нем действительно есть рациональные зерна. Конкретно же нужно субъективно (а как же еще ) нужно оценить объемы и скорость модификации, оценить вероятность и частоту залезания в прошлые периоды, выбрать оптимальные интервалы, схему обновления. Короче, вопрос этот требует медитации...