While I agree with the general take on this subject ("Never store totals
without a good reason" and "where there is duplication there is the
opportunity for skew"), I must say that there are exceptions. A couple of
years ago I worked on an inherited database in which the operant principle
was "sum don't store"; the problem was that many of the rows summed dated
back a year or two or more, and as an accountant friend of mine loved to
say, "A paid transaction is history; an unpaid transaction is fiction." In
other words, repeatedly summing amounts dating from last year or the year(s)
before is a waste of time and energy. An approach much superior in
performance is to store History in one summary table and Current in the
actual transaction table. Then all no sums or other calculations are
required for the History portion of the final calculation or presentation or
whatever it is. You grab and sum this (fiscal) year's rows, and then look up
the numbers for previous year(s). When you're dealing with say a million
rows per year, this change can dramatically improve performance.Just my $0.02". Arthur
