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.

• ✗

  When you have a high write-to-read ratio for the specific data field.

  Why it's wrong here

  If writes are more frequent than reads, updating the computed value in the document every time a write occurs will create significant overhead and potential lock contention. The computed pattern is optimized for read-heavy workloads where the cost of reading the stored value is lower than calculating it repeatedly.

• ✓

  When the data is accessed frequently and requires an expensive calculation.

  Why this is correct

  Pre-computing expensive values and storing them in the document allows for lightning-fast reads. The application avoids the performance penalty of re-calculating results (like sums or averages) during every query. This is a classic trade-off where storage space is exchanged for significant gains in read performance and application responsiveness.

• ✗

  When you need to store binary large objects (BLOBs) in the database.

  Why it's wrong here

  The computed pattern is about numeric or aggregate results, not binary data. Storing BLOBs should be handled via GridFS or by keeping the data in separate collections if they exceed document size limits. Using this pattern for binary storage would be a misuse of the design principle.

• ✗

  When you want to prevent all indexing on a specific collection.

  Why it's wrong here

  The computed pattern has no relationship to index management. Indexing is crucial for query performance in MongoDB regardless of whether you use computed fields or not. Suggesting this pattern as a way to avoid indexing is incorrect and would lead to disastrous performance for any non-trivial application.