Exercise 2: Why barcode Is a Primary Key in One Table but Not the Other — Possible Solution ==================================================================== WHAT'S TRUE FOR BarcodeCache ------------------------------ BarcodeCache stores one cached product lookup per barcode - there's genuinely only one correct cached answer for a given barcode at any point in time, so declaring barcode as the primary key correctly enforces that at most one row can ever exist per barcode. WHAT'S TRUE FOR Item INSTEAD ------------------------------ The Item table records individual pantry purchases, not products - the same barcode can legitimately appear on many separate rows, because the same product might be bought, used, and bought again multiple times, each purchase being its own distinct row with its own expiry date and status. Making barcode a primary key on Item would incorrectly prevent recording a second purchase of a product already bought before. WHY THIS WORKS AS AN ANSWER ------------------------------ It correctly explains that a primary key enforces at-most-one-row-per-value, correctly identifies that this is genuinely true for BarcodeCache (one cached lookup per barcode), and correctly identifies that the same is not true for Item, since the same barcode legitimately recurs across multiple separate purchases over time.