Exercise 2: Why barcode Is a Primary Key in One Table but Not the Other — Possible Solution
====================================================================

WHAT A PRIMARY KEY ACTUALLY MEANS HERE
------------------------------
A primary key enforces that a value can appear at most once across all rows in that table - it's the correct constraint whenever "this value uniquely identifies one record" is actually true for the data being modeled.

WHY IT'S TRUE FOR barcode_cache
------------------------------
barcode_cache stores one cached product lookup per barcode - there's genuinely only one correct answer to "what does this barcode look up to," so barcode being the primary key correctly reflects that a given barcode should only ever have one cached entry.

WHY IT'S NOT TRUE FOR items
------------------------------
The items table stores individual pantry purchases, not products - the same barcode can legitimately appear on many separate rows, because the same product can be bought, used, and bought again multiple times, each purchase being its own distinct item with its own expiry date and status. Making barcode a primary key in items would incorrectly prevent buying the same product twice.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that a primary key enforces uniqueness, correctly identifies that one-barcode-to-one-cached-lookup is genuinely true for barcode_cache, and correctly identifies that the same is not true for items, since the same barcode legitimately recurs across multiple separate purchases.