Arm79,

свертка не имеет отношения к сути вопроса - если есть возможно оптимизировать Бд ею пользуются.
Сколько бы клиентов и записей ни было - пересчет данных (суммирование оборотов для получения остатка будет идти по строкам выбранных в соответствии с индексом (который как правило кешируется в памяти).
Безусловно по мере разрастания данных выборка для пересчета будет медленнее, но это касается и ЛЮБОЙ другой выборки, например какого нибудь поиска.
Но наличие большого обьема памяти позволит серверу Бд кешировать наиболее часто запрашиваемые данные в памяти. Как правило большинство отчетов делаются за определенный период - текущий месяц, квартал и т.д. Поэтому боьшая вероятность что после первой выборки для пересчета части таблиц с оперативной информацией за этот период окажутся закешированными. Впрочем это тоже касается любой выборки.
С другой стороны - у нас тысячи клиентов и по каждому (точнее по каждому счету если их у клиена больше одного) надо хранить остатки например на начало месяца - тоже нехилый обьем. При выборке нам надо вычислить от каких остатков плясать - обратится к таблице остатков, затем обратится к таблице движений чтоы получить обороты и просуммировать. не уверен что это будет намного быстрее не говоря уже о более сложной выборке (уж точно не простейший select sum() как при пересчете).
ну и плюс еще эти остатки надо высчитывать и запоминать. и хорошо если в системе не надо проводить операции задним числом (лично я в наших реалиях таких не видел) с последующим песчетом остатков как в той же 1С.
С третьей стороны - на примере работы с приват24 я вижу что данные все равно получаются не сразу. я не знаю как там у них написано - но я делаю транзакцию а результат (обновление на странице или СМС на телефон приходит иногда чере несколько минут). а раз добится мгновенного отклика системы все равно нельзя (или просто не имеет смысла) то чего усложнять систему.
А для манаегров которые там просматривают всякие сводные данные как правило строятся всякие олапы с предагрегациями - но это уже совсем другая задача с другими методами.
Как бы там ни было даже если окажется в далеком будущем что есть необходимость хранить промежуточные остатки (ы чем я лично сомневаюсь глядя как растет производительность серверов) это можно будет сделать потом не переделывая всю систему. На данный момент вполне можно руководсвоватся дним из програмистских правил - преждевременная оптимизация - зло.

Впрочем как говорят в Одессе - это "мое ИМХО". Истина только в бенчмарках :)

Dimitry SibiryakovcaballeroЛЮБОЕ приложение будет работать медленнее по мере накопления данных
НЕЗАВИСИМО от того каким образом запрограмировано получение этих данных. Так что вы
хотите доказать?
Он хочет сказать, что если приложение не программировать, то оно и не будет работать
медленнее. Сферические кони в вакууме не замедляются.

Он сам не понимает что хочет сказать, прост лепит первое что в голову придет. Непонятно только почему надо флудить на програмистском форуме а не в предназначенном для этого каком нибудь вконтакте.