Exercise 2: Why BarcodeCache's Primary Key Differs From Item's — Possible Solution
====================================================================

WHY BarcodeCache USES barcode AS ITS PRIMARY KEY
------------------------------
BarcodeCache exists to store exactly one canonical record per product - there's only ever one name/category worth caching for a given barcode, regardless of how many times that product is ever looked up. Since the collection's own purpose is genuinely one-record-per-barcode, using barcode directly as the primary key causes no conflict and is the correct, natural choice.

WHY Item DOES NOT USE barcode AS ITS PRIMARY KEY
------------------------------
Item tracks individual purchased instances of a product, and the same barcode can legitimately appear across many different Item rows - the same product bought and tracked multiple times, each with its own separate expiry date and lifecycle. Using barcode as Item's primary key would break the moment the same product was purchased a second time, since a primary key must be unique per row.

THE CONNECTION TO THE FIREBASE SIBLING COURSE
------------------------------
The Firebase-based sibling course faced the identical question for its own items and barcodeCache collections: items (many purchases can share one barcode) avoids barcode-as-ID, while barcodeCache (exactly one record per barcode) uses it directly. Both courses reach the same conclusion independently, because the underlying cardinality of what each collection/table represents is the same in both architectures - this is a genuine data-modeling principle, not something specific to either database technology.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains the differing cardinality behind each model's primary-key decision (one-per-barcode for BarcodeCache vs. many-per-barcode for Item), and correctly connects this to the Firebase sibling course's identical resolution of the same underlying question.