On 03/09/2010 16:32, Arthur Fuller wrote:
> 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."
The other exception is also where financial data is being stored. If you
have, say, a database containing sales order records, then as well as
storing the individual values of each item in each order, you also need
to store the total value of the order, the total price charged to the
customer and the total paid by the customer. These three should, of
course, be not only identical to each other but also to the sum of the
individual items, so there is not only duplication but the potential for
skew. But that, of course, is precisely *why* you store them, as any
discrepancy indicates an error which needs to be investigated.
Mark
--
http://mark.goodge.co.uk
