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 Bucket Pattern to group products by category into buckets of 100 documents.

  Why it's wrong here

  The Bucket Pattern is designed for time-series data or high-volume streams to reduce document count and index size, not for storing heterogeneous product data. Grouping products into buckets would complicate queries that need to filter on individual product attributes and would not provide efficient indexing for those attributes. It is not suitable for this scenario.

• ✗

  Embed all possible category-specific attributes in every product document, using null for missing attributes.

  Why it's wrong here

  Embedding all possible attributes in every document wastes storage and creates sparse indexes that are inefficient. It also requires schema changes whenever a new attribute is introduced, reducing flexibility. This approach contradicts the goal of a flexible schema and can lead to large documents and poor query performance due to many unused fields.

• ✓

  Use the Polymorphic Pattern to store all products in one collection with a 'category' field and include category-specific fields at the top level.

  Why this is correct

  The Polymorphic Pattern allows documents in the same collection to have different shapes, which is perfect for products with varying attributes. By including a 'category' field, the application can easily filter by category and access the specific attributes. This approach provides flexibility and is a common MongoDB design pattern for heterogeneous data, enabling efficient queries on category-specific fields when indexed appropriately.

• ✓

  Use the Attribute Pattern to store category-specific attributes as an array of key-value pairs, and create a compound index on the keys and values.

  Why this is correct

  The Attribute Pattern converts variable attributes into an array of key-value documents, which can be indexed with a compound index on the key and value fields. This allows efficient querying on any attribute without needing to know all possible fields in advance. It is ideal for this scenario where different categories have different attributes and queries filter on them, providing both flexibility and query performance.

• ✗

  Create a separate collection for each product category with its own schema and indexes.

  Why it's wrong here

  Creating separate collections per category leads to a proliferation of collections and complicates application logic, especially when querying across categories. It also makes it difficult to maintain a unified product catalog. While it allows tailored indexes, it sacrifices the flexibility and simplicity of a single collection, which is a core strength of MongoDB. This approach is generally not recommended for this use case.