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.

• ✓

  Store all items in one collection and include only the attributes relevant to each item's category.

  Why this is correct

  The Polymorphic pattern keeps documents with similar shared fields in one collection while allowing category-specific fields to differ. Queries across all items, such as by name or price, stay simple, and category-specific queries filter on the shared 'category' field. This matches the scenario's mix of common and divergent attributes.

• ✗

  Create one collection per category, such as 'books' and 'electronics', and never query across them.

  Why it's wrong here

  Splitting into separate collections complicates any query that spans categories, such as finding items under a price threshold or searching by name. It also duplicates shared logic and indexes. The scenario explicitly notes shared fields, which is a signal to keep documents together rather than partition by category.

• ✗

  Normalize all attributes into a separate 'attributes' collection referenced by item documents.

  Why it's wrong here

  Normalizing into a referenced collection requires a $lookup for nearly every read and adds join cost. The attributes are few and belong to the item, so referencing them is unnecessary overhead. This approach fits highly variable, shared, or large attribute sets, not the small category-specific fields described here.

• ✗

  Store all category-specific attributes in a single 'attributes' array of key-value pairs for every item.

  Why it's wrong here

  A generic key-value array loses per-field typing and makes indexes and validation awkward. Queries become nested array matches, and sorting or range queries on numeric attributes are inefficient. While flexible, this approach sacrifices the schema clarity that the Polymorphic pattern preserves by keeping named fields.