Personal Catalogue: React, Express & MongoDB — Chapter 1, Exercise 1
=====================================================================

TASK
Explain why a genuinely heterogeneous MongoDB collection is a better fit
for this project's own item data than a single, rigid relational table —
and name the real risk a document database doesn't automatically protect
against that a relational one does.

SOLUTION

Books, CDs, DVDs, and Blu-rays share only a few real fields (title,
format, year) and diverge sharply everywhere else: a book needs author,
ISBN, and publisher; a DVD needs director, runtime, and disc format; a
CD needs artist and tracklist. Forcing all four into one relational
table means either a very wide table full of columns that are NULL for
most rows (a DVD row has no ISBN, a book row has no runtime), or
splitting into four separate tables joined back together for any
"show me everything" view.

MongoDB's own document model sidesteps that tradeoff directly. A single
`items` collection can hold a book document with exactly the fields a
book needs and a DVD document with exactly the fields a DVD needs, side
by side, with no wasted columns and no early commitment to one shared
shape. Mongoose discriminators (covered properly in Chapter 2) add real,
per-type schema validation on top of that flexibility, so "flexible"
doesn't mean "unvalidated" — each item type still has to match its own
schema before MongoDB accepts it.

The real risk this flexibility doesn't automatically protect against is
referential integrity. A relational database's own foreign key
constraints can guarantee, at the database level, that a tag actually
points at a real, existing book — MongoDB has no equivalent built-in
guarantee. If a book document is deleted, nothing at the database layer
stops a tag reference to it from silently going stale. That has to be
handled explicitly in application code, a real tradeoff worth knowing
about up front rather than discovering later.

WHY THIS WORKS AS AN ANSWER
----------------------------
It identifies the real structural mismatch (genuinely different fields
per item type) rather than a vague "MongoDB is more flexible" claim,
names the concrete mechanism (Mongoose discriminators) that keeps that
flexibility from becoming unvalidated chaos, and correctly identifies
the real tradeoff — no automatic referential integrity — that a
relational sibling course doesn't have to think about.