Прочитал на хабре статейку тынц и задумался - для своих сложных отчетов я данные рассчитывал при вставке каждой записи, но данный подход может не работать на очень больших объемах и при большой интенсивности запросов к БД.
В статье обсуждается альтернативный метод.
Как в приличных публичных заведениях решается вопрос агрегатирования данных для построения отчетов (имеется в виду не только вычисление средних значений. а и накопительные суммы по определенным разрезам (периодам, счетам, лицам))

Спасибо.

_модspКак в приличных публичных заведениях решается вопрос агрегатирования данных для построения отчетов (имеется в виду не только вычисление средних значений. а и накопительные суммы по определенным разрезам (периодам, счетам, лицам))

Простой отчет: один запрос с динамическим вычислением итогов
Сложный отчет: засасываем в ОП все необходимые данные, агрегируем и выводим в отчет

а ежели засосать в ОП надо данные о миллионах операций??? могут все и не влезть? дык и в ОП еще разные всякие сидят, не только ж SQL!

_мод,

Помницца нам еще в школе говорили, что так нельзя и приводили пример такой абстрактной как бы компании с названием как бы VISA и что если бы по концу месяца она стала делать отчет об остатках на счетах, так как предлагаете вы, ее б как бы абстрактное название никогда бы не упоминалось в учебных примерах!

_модspа ежели засосать в ОП надо данные о миллионах операций??? могут все и не влезть? дык и в ОП еще разные всякие сидят, не только ж SQL!
Сам по себе отчет не может быть очень большим - его никто не прочитает. Следовательно данные можно частично агрегировать уже при вводе. Да и ОП сейчас большая. Причем я имею ввиду ОП клиента.

в юзании ОП клиента - я с вами полностью солидарен, и делаю уже так давно
но меня вот поразило использование матаппарата при расчете агрегированных данных, и сэкономленное время и память - что вижу вообще впервые, такое впечатление что с SQL никто математику не прикручивал - ни одной подобной статьи ранее не видел....
Может есть еще какие-то интересные методы...?