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.

• ✗

  Use the Schema Versioning Pattern with a 'schema_version' field and store attributes in version-specific subdocuments.

  Why it's wrong here

  Schema versioning addresses schema evolution over time, such as adding a required field or restructuring documents during a migration. It does not address the coexistence of multiple entity shapes at the same point in time. Using version numbers for categories would conflate temporal changes with structural variety, making queries harder and providing no benefit for the stated requirement of filtering on category-specific attributes.

• ✗

  Store all attributes in a single generic 'attributes' array of key-value pairs without a category field.

  Why it's wrong here

  A generic key-value array loses the ability to use a discriminator for routing and makes queries awkward because every filter must match against array elements rather than named fields. It also weakens validation, since nothing prevents a book from having wattage. Without a category field, the application cannot easily apply category-specific rules or indexes, so this design trades structure for flexibility that is not needed.

• ✓

  Use the Polymorphic Pattern by storing all products in one collection with a 'category' field and category-specific attributes in a shared subdocument.

  Why this is correct

  The Polymorphic Pattern keeps all related documents in a single collection even when their shapes differ, using a discriminator field such as 'category' to identify the variant. This allows a single query to filter across shared and type-specific attributes, and indexes can cover the fields each category uses. It matches MongoDB's flexible schema and avoids collection sprawl or application-side joins.

• ✗

  Create a separate collection for each product category and route queries based on category.

  Why it's wrong here

  Separate collections force the application to know the category before querying and make cross-category searches (such as a unified product search) require multiple queries and application-side merging. This approach also complicates shared attributes like price and brand, which would need to be duplicated or joined. It solves attribute variety by fragmenting data rather than modeling it, adding significant application complexity.