Проектирую учётную систему... СУБД MySQL5
есть абаненты со своими счетами, им начисляются определённые суммы
хранится это в табличке:
transact_charge
- tr_id
- score_num
- tr_month - за какой месяц
- tr_year - за какой год
- tr_value
-...
когда абаненты оплачивают, то это заносится в табличку
transact_payment
- tr_id
- score_num - счёт абанента
- tr_date
- tr_value
-...
всё отлично собирает, считает...
отчёты - счета абанентов разбиваются по группам, и по этим группам на указанный месяц выводятся суммы, остатки, долги..
начали смотреть производительность, забили несколько тысяч абанентов, начислили им за "услуги" на ближайщие пять лет, смоделировали как они расплачивались за услуги..
стали пробовать генерить отчёты - ну очень долго, на моём компе Пень2,8 - запрос в среднем 15...20 секунд....Это уже после оптимизации, создания индексов и т.п.... у заказчиков машины ещё слабей.. пробовали - генерация по несколько минут, что неприемлимо.
Плюс появились проблемы с висяками из-за глюков компанентов клиента...

в общем сейчас переделываю на PostgreSQL, стараюсь учесть предыдущий опыт :)

почитал тему
/topic/383791

для себя выбрал схему хранения промежуточных сумм
т.е. суммы по группам абанентов, будут считаться при внесении или начислении через триггер
и при получении отчётов, будут браться эти суммы, а не рассчитываться чуть ли не по всей базе

эти дополнительные суммы будут использоваться исключительно для отчётов

вот теперь сам вопрос, где лучше хранить эти суммы?
в тех же самых таблицах (transact_charge & transact_payment) добавив поля для указания периода за который сумма хранится или создать отдельные таблицы?

понятно, что всё будет пробоваться... но интерестно, кто как делает и какой вариант чем лучше/хуже

babaEGAНо думаю, вам нужно сделать некую денормализацию.
Я заинтригован, что вы имели в виду под денормализацией?

babaEGAНе совсем поняла что это за таблицы.
ну допустим, таблица, в которой указывается за что и сколько заплатил абанент
transact_payment
- score_num - номер счёта абанента
- value - сколько он заплатил
- date - дата оплаты

Записей в этой таблице может быть под миллион (после пары лет использования программы)
Когда генерируется отчёт, включающий в себя множественные подзапросы к таблице transact_payment ... в общем долго генерируется

как один из вариантов "ускорения", хранить ещё и промежуточные суммы, которые пересчитываются, при заполнении таблицы... такой рассчёт будет милисикунды, это не затормозит работу, а вот скорость получения отчёта вырастет в разы
промежуточные суммы можно хранить в той же таблице transact_payment , добавив пару столбцов
либо в отдельной, например transact_payment_sum

В процессе изысканий, решил делать отдельную таблицу для промежуточных сумм