Challenge 3: MongoDB or MySQL? — Possible Solution
====================================================================

(a) A product catalog where each product category has wildly
    different attributes
    -> RECOMMEND: MongoDB.
    Justification: a "shoes" product might need size and width fields,
    while a "laptop" product needs RAM and screen-size fields entirely
    unrelated to shoes — trying to force every possible attribute
    across every category into one fixed set of relational columns
    typically ends up with a table full of mostly-NULL columns, or an
    awkward separate attributes table joined back in. MongoDB's
    schema flexibility handles this naturally: a "shoes" document and
    a "laptop" document can simply have different fields, with no
    wasted NULL columns and no extra join needed to read a single
    product's full attribute set.

(b) A banking system tracking transfers between accounts that must
    always balance exactly
    -> RECOMMEND: MySQL.
    Justification: this scenario is precisely the "MySQL still wins"
    case the chapter described — strong relational integrity and
    guaranteed transactional consistency across multiple entities
    (debiting one account and crediting another must either BOTH
    succeed or BOTH fail, with no in-between state ever visible).
    Relational databases like MySQL are built around exactly this
    kind of enforced, atomic multi-table consistency; while MongoDB
    does support multi-document transactions (covered later in this
    course), the underlying data itself here is fundamentally
    relational and benefits from MySQL's foreign-key-enforced
    structure rather than a document model built around flexible,
    independently-evolving shapes.

WHY THIS WORKS AS AN ANSWER
------------------------------
The deciding factor in both cases is the SAME property flipped in
opposite directions: (a) needs flexibility because the data's shape
genuinely varies case by case, which is exactly what MongoDB is built
to handle well; (b) needs strict, enforced consistency across
multiple related pieces of data, which is exactly what a relational
database's constraints and transactional guarantees are built to
provide. Neither answer is about one database being "better" in
general — it's about which one's core strength actually matches the
problem.