Practice — Mild · Solution
Checkpoints, verified
| Stage | Figure |
|---|---|
| Append of six files | 26,139 rows (Jan 3,903 · Feb 3,412 · Mar 4,182 · Apr 4,454 · May 5,304 · Jun 4,884) |
| products.csv key profile | 240 rows, 240 distinct ProductIDs |
| After Left Outer merge + expand Category | 26,139 rows — unchanged |
| Quantity by Category | Outdoor 9,439 · Lighting 9,107 · Kitchen & Dining 8,378 · Furniture 8,065 · Decor 6,191 |
Notice the monthly row counts themselves tell the seasonality story: May's file is 36% bigger than February's. Nothing is wrong with either file — fire-pit season is simply real, a fact the Hot practice will make someone defend under pressure.
Reflection answers
- Profiling the key (240 rows = 240 distinct) rules out the multiplying merge: duplicate right-side keys multiply matching left rows, and the symptom would have been a post-merge count above 26,139. Ten seconds of profiling versus an inflated table shipped to a VP.
- Because the join kind is a recorded claim, not a result. Today Inner and Left Outer coincide; the day a new product appears in sales before someone updates products.csv, Inner silently deletes those sales and Left Outer keeps them with a null category — visibly, fixably. Choose the claim that fails loudly.