Exercise 2: Why Not the Barcode as Document ID — Possible Solution
====================================================================

WHY THE BARCODE SHOULDN'T BE THE DOCUMENT ID
------------------------------
Per this chapter, the same product - and therefore the same barcode - can genuinely be purchased and tracked more than once, with each purchase having its own separate expiry date and its own separate lifecycle (added, expiring, used). A document ID needs to uniquely identify one purchased instance of an item, not the product itself. If the barcode were used as the document ID, buying the same product a second time would either overwrite the first purchase's document entirely, or require some awkward workaround to avoid the collision - neither of which correctly represents "two separate cartons of yogurt with two separate use-by dates."

WHAT SHOULD BE USED INSTEAD
------------------------------
An auto-generated document ID, assigned by Firestore itself when the document is created, with the barcode stored as an ordinary field on the document (alongside name, category, etc.) rather than used as the identifying key.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies that a barcode identifies a product, not a specific purchased instance, explains the concrete collision problem that would result from using it as a document ID, and correctly recommends Firestore's own auto-generated document ID with the barcode kept as a regular field.