Exercise 3: Why barcode Is the Primary Key on One Model, Not the Other — Possible Solution
====================================================================

WHAT EACH MODEL'S barcode FIELD ACTUALLY REPRESENTS
------------------------------
On BarcodeCache, barcode identifies a single cached product lookup —
there is only ever supposed to be one cached record per barcode, since
looking the same barcode up twice should return the same cached product
information both times. That's exactly what a primary key means: at
most one row per value.

On Item, barcode identifies which product a particular pantry entry
corresponds to — but the same real-world product can legitimately be
bought, added, used, and bought again many times over. Each of those is
a genuinely separate row in Item (a separate purchase, with its own
expiry date, its own added/used timestamps), all sharing the same
barcode value. Making barcode the primary key on Item would make it
impossible to record a second purchase of a product already tracked
once before.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly distinguishes what each field is actually modeling —
"one cached lookup per barcode" versus "potentially many separate
pantry entries that happen to share a barcode" — rather than treating
the two barcode fields as interchangeable just because they have the
same name and type.