Challenge 2: Design a Many-to-Many Relationship — Possible Solution
====================================================================

// authors collection
{ _id: ObjectId("a1"), name: "Jane Smith" }
{ _id: ObjectId("a2"), name: "Tom Reid" }

// books collection
{ _id: ObjectId("b1"), title: "Deep Learning Foundations" }

// bookAuthorships collection — the join collection carrying the
// relationship's own data (royalty percentage)
{ authorId: ObjectId("a1"), bookId: ObjectId("b1"), royaltyPercent: 60 }
{ authorId: ObjectId("a2"), bookId: ObjectId("b1"), royaltyPercent: 40 }

WHY THIS WORKS AS AN ANSWER
------------------------------
A plain array of references on either side (e.g. just storing a list
of authorIds directly on the book document, or a list of bookIds on
each author) would work for representing WHO wrote WHAT, but it has
nowhere to put the royalty percentage — that number belongs to the
RELATIONSHIP between a specific author and a specific book, not to
either side alone (the same author might have a different royalty
split on a different book).

The join-collection pattern solves this directly: each document in
bookAuthorships represents exactly one author-book pairing, and can
carry whatever additional data belongs to that specific pairing. This
is precisely the document-model equivalent of a MySQL join table with
extra columns beyond the two foreign keys — the same underlying
need (a many-to-many relationship that itself has attributes) gets
solved the same structural way in both database styles, just
expressed as documents instead of rows.