Practice — Medium · Solution
Part 1 — the verified counts
| Join kind | Rows | The reasoning a good prediction used |
|---|---|---|
| Left Outer | 26,139 | Left joins preserve the left table when the right key is unique — and customer_export has 500 rows, 500 distinct IDs |
| Inner | 1,627 | 500 customers of ~6,544 active in H1 — order-of-magnitude thinking says "a small fraction survives"; ~6% of lines is in that ballpark |
| Left Anti | 24,512 | Whatever Inner kept, Anti discards, and vice versa |
Inner + Left Anti = 26,139, always, exactly — they partition the left table into matched and unmatched. If your two results do not sum to the left table's count, one of the merges was keyed or configured differently. That identity is a free consistency check whenever you run both.
Part 2 — the crosstab
- Two identity columns, twelve month columns → prediction 30 × 12 = 360, and the run confirms it.
- The Month column profiles at 12 distinct values — one per month of 2026. Eleven or thirteen would mean a month column got lost before the unpivot or an identity column fell in.
Reflection answers
- Most students miss Inner — usually predicting close to 26,139, believing "most sales surely match." The corrected belief: match rates are a property of the lookup's coverage, not of hope — and a 500-person marketing sample covers very little of a 6,544-customer half-year.
- Predict-then-run catches plausible wrongness. An unexpected 1,627 is alarming only if you expected 26,139; with no expectation, 1,627 "looks reasonable" and ships. Checking afterward without a prediction is how the inner-join disaster gets a professional paint job.