Parting Shots

The temptation is always strong to store aggregate values somewhere in the databasein a summary column, a summary row, or even a summary table. In a data warehouse, this is a natural inclination and everyone realizes that it's faster to look up a calculated value than to recalculate the value. In an Online Transaction Processing (OLTP) environment, stored summaries are rarer for the following reasons: (a) updates that happen in two places are prone to error; and (b) if a specific query is really frequent, then it will be cached anyway.

The temptation is occasionally strong to calculate aggregate values on the client instead of on the server. This is possible if you have a read-only result set and you can program in a host language. (We have seen this recommended as a tip in some MySQL- related books.) In many shops , client-side aggregating is forbidden because it doesn't save enough to make up for the extra programming time and network transmission time.

The temptation should be strong to avoid GROUP BY and aggregate functions entirely. We can only hope that some of what we've said here will make them more palatable.