MongoDB MongoDB Schema Design and Data Modeling 2 — Questions and Answers
Question 1: Which MongoDB schema design pattern duplicates data to avoid frequent joins and optimize read performance?
- Normalization pattern
- Extended Reference Pattern (Correct answer)
- Outlier Pattern
- Computed Pattern
Correct answer: Extended Reference Pattern
The Extended Reference Pattern copies a subset of frequently accessed fields from a referenced document into the referencing document. This avoids expensive $lookup operations for the most commonly needed fields, trading some write duplication for faster reads.
Question 2: What problem does the Computed Pattern solve in MongoDB?
- It pre-computes and stores results that are expensive to calculate on every read (Correct answer)
- It computes shard keys automatically
- It resolves schema conflicts between collections
- It computes index statistics in real time
Correct answer: It pre-computes and stores results that are expensive to calculate on every read
The Computed Pattern pre-calculates expensive values (e.g., totals, averages, counts) and stores them in the document. Instead of running costly aggregations on every read, the application reads the pre-computed value and updates it periodically or on write.
Question 3: When should you prefer referencing over embedding in MongoDB?
- When data is always accessed together and fits within 16 MB
- When related data is large, changes frequently, or is accessed independently (Correct answer)
- When you need to avoid all multi-document reads
- When using a single-node replica set
Correct answer: When related data is large, changes frequently, or is accessed independently
Referencing is preferred when related data is large (risking document size limits), changes frequently (avoiding expensive rewrites of the parent document), or is frequently accessed independently. It keeps documents manageable but requires additional queries or $lookup.
Question 4: What is the purpose of schema versioning in MongoDB?
- To lock the schema for production deployments
- To allow gradual migration of documents to a new schema without downtime (Correct answer)
- To version control the database binary
- To automatically upgrade field types on insert
Correct answer: To allow gradual migration of documents to a new schema without downtime
The Schema Versioning Pattern adds a 'schema_version' field to documents. Application code handles multiple versions simultaneously, allowing lazy migration — old documents are updated to the new schema when they are next read or written, avoiding a big-bang migration.
Question 5: Which of the following best describes a one-to-zillions relationship in MongoDB schema design?
- A parent document with a small embedded array
- A relationship where millions of child documents point to one parent, making embedding impractical (Correct answer)
- A many-to-many relationship handled by an intermediate collection
- A self-referencing document structure
Correct answer: A relationship where millions of child documents point to one parent, making embedding impractical
One-to-zillions describes relationships where the child side is unbounded and potentially enormous (e.g., log entries for a server). Embedding is impossible due to document size limits. Instead, each child document stores a reference to the parent — the reverse of typical embedding.
Question 6: What is the Tree Pattern used for in MongoDB?
- Indexing documents in a B-tree structure
- Representing hierarchical data such as organizational charts or category trees (Correct answer)
- Sorting documents in tree traversal order
- Generating decision trees from documents
Correct answer: Representing hierarchical data such as organizational charts or category trees
The Tree Pattern models hierarchical data in MongoDB. Common representations include Parent References (each node stores its parent's _id), Child References (each node stores children's _ids), Array of Ancestors, and Materialized Paths — each with different trade-offs for query patterns.
Which MongoDB schema design pattern duplicates data to avoid frequent joins and optimize read performance?