SQL Child / Summarising Safely

Never Summarise Data You Have Already Duplicated

The two most common errors in this subject combine into something considerably worse than either alone.

Accidental multiplication when combining collections is survivable on its own, because the repetition is usually visible if you look at the detail. Summarising is safe on its own, because the arithmetic is straightforward. Do them in sequence and you get an error that is both invisible and confident. The repetition is folded into a single figure, all evidence of it is discarded, and what emerges is a clean number that is wrong by a factor nobody can determine after the fact. This is how organisations end up with two departments quoting different revenue figures and no way to reconcile them.

What makes it so persistent is that the wrong number is often only somewhat wrong. If most customers have one address and a handful have two, your inflated total might be four per cent high. It will not look absurd. It will not trigger anyone's instinct. It will simply be slightly too large forever, and every downstream calculation built on it will inherit the error. Errors large enough to be obvious get fixed within a day. Errors of a few per cent live for years and do far more cumulative damage.

The discipline is a sequence, and it is worth making automatic. Combine your collections. Count your lines. Compare that count against what you had before and explain any growth in words. Look at the detail for a single known example, one customer whose situation you understand, and confirm that they appear the number of times you expect. Only then summarise. It is perhaps two extra minutes of work and it is the closest thing to insurance this subject offers. Nobody who has been burned once ever skips it again.