Question

I don’t have much experience with databases, so I don’t know which is better for long-term performance, better practice, etc.

Here is my (hypothetical) case: imagine you have a database of customer information and history of purchase orders for each. You want to keep track of how much each customer is buying. I can think of two ways of calculating this:

1) Just do a SUM() every time it is needed. This is an easy solution, but the concern is that this database could be 20 years old with tens of thousands of rows for each customer. As more customers purchases are added to the database, the SUM() operation will take longer to calculate.

2) Keep the sum cached in the customer information table, and every time a new purchase is made (updated, deleted, etc), update this cache. That way no matter how many purchase orders there are, there won’t be an increase in the calculation time. The downside is that, this is a less flexible solution (only the sum over all rows, what about per month sum? other intervals? etc); this cached value could get out of sync with the actual total somehow (technically shouldn’t happen, but it might)

So what should I be doing for this? I know I shouldn’t be storing anything I can calculate from what’s already in the database, but part of me doesn’t like the fact that this type of calculation will get worse in time, and that there is some kind of elegance to option 2.

Answer 1

In database terms, there is no elegance in option 2 – it would be considered a hack that you might use as a last resort if your database gets to be truly humongous – not likely to happen for a novice setting it up for the first time (but possible).

There would be a lot of work maintaining the totals; and you’d be forever dealing with the question: ‘Why doesn’t the detail add up to the total?’

Go for option 1 until you’ve proven you can’t. Which will in most cases be a long time.