Challenge 2: Model a Blog Post as a Document — Possible Solution
====================================================================

{
  "_id": ObjectId("64f2b7..."),
  "title": "Why I Switched to MongoDB",
  "body": "...",
  "author": "Alice",
  "publishedAt": ISODate("2026-03-01"),
  "comments": [
    { "author": "Bob", "text": "Great post!", "postedAt": ISODate("2026-03-02") },
    { "author": "Carla", "text": "Disagree, but interesting.", "postedAt": ISODate("2026-03-02") }
  ]
}

WHY THIS WORKS AS AN ANSWER
------------------------------
The relational design needed a separate comments table specifically
because a table's rows can't naturally hold a variable-length list of
"sub-items" inline — each comment had to be its own row, tied back to
its post via a foreign key, and reassembling "this post plus all its
comments" required a JOIN across both tables.

MongoDB's document model doesn't have that restriction: since a
document is a single JSON-like structure, it can directly contain an
ARRAY of comment objects nested inside the post document itself. This
is exactly the embedding approach the chapter described as one of
MongoDB's natural fits — data that's always read and written together
as one unit (a post is essentially always displayed WITH its
comments) can be modeled as one single document, with no join
required at read time at all.

Worth noting as a design consideration (not required for this
challenge, but good practice to be aware of): embedding comments works
well as long as a single post doesn't accumulate an enormous, ever-
growing number of them — a concern the course revisits later with
schema design patterns for scale.