Field note · March 31, 2026

The total came out 34.6× too high

34.6 rows per key on one table, and the totals that quietly inherit the multiplier.

1 min read ·Analytics engineering ·sql quality

A fan-out, arithmetic first. movie-ratings has 9,000 rows and 260 distinct movie_id values.

That is 34.6 rows per movie on average. Join anything to this table on movie_id and every row on the other side is duplicated that many times. If the other side carries a number you then sum, the sum is wrong by roughly that factor.

The reason it is hard to catch is that nothing fails. The query runs, the join is valid, and the result is a plausible-looking number that is 34.6 times too large.

sql
-- the check, before the join
select count(*) as rows, count(distinct movie_id) as keys
from movie_ratings;
-- rows 9,000, keys 260 → not unique

-- so aggregate to the grain you want first
with per_key as (
  select movie_id, sum(release_year) as release_year
  from movie_ratings
  group by 1
)
select * from per_key;

Aggregating before the join is the fix that generalises. The alternatives — joining and then deduplicating, or select distinct over the result — both work occasionally and hide the problem the rest of the time, because they remove duplicate rows rather than duplicate contribution.

The two-line cardinality check above is cheaper than the incident. It belongs in front of every join you did not write yourself. Longer version in Joins that do not fan out and the fan-out pattern.