C100DEV Data Modeling Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Add an index on the embedded supplier.address field so updates to that field become faster.

  Why it's wrong here

  Indexes accelerate reads and queries, not the cost of updating thousands of duplicated embedded copies. Each product document still contains its own copy of the address, so a supplier move still requires writing every product document; the index would actually add write overhead because it must also be maintained. The fundamental duplication problem remains unaddressed by this change.

• ✗

  Move the supplier subdocument into an array field so all supplier versions are retained for auditing.

  Why it's wrong here

  Storing historical supplier versions in an array increases document size, complicates queries because the current supplier must be distinguished from past ones, and still duplicates address data across every product. It does not reduce the number of writes required when an address changes; it multiplies them and makes the schema harder to reason about for routine lookups.

• ✗

  Use the Schema Versioning Pattern by adding a version field to each product document and migrating documents lazily.

  Why it's wrong here

  Schema versioning helps when the shape of documents must change over time without a full downtime migration, for example adding a new required field. Here the schema shape is fine; the problem is duplicated mutable data. Adding a version field would not stop the need to update every product when a supplier moves and would add migration complexity unrelated to the actual maintenance issue.

• ✓

  Convert the supplier subdocument to a reference by storing the supplier's ObjectId in the product document and keeping supplier details in a suppliers collection.

  Why this is correct

  When an entity like a supplier is updated independently and shared by many parent documents, referencing avoids duplicated data. Storing only the supplier's ObjectId lets a single update to the suppliers collection propagate to all products, eliminating the mass-update problem while keeping document sizes small and consistent with MongoDB's recommendation to embed for locality but reference for independently mutated shared data.