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
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[email protected]
