Why modeling decisions matter in MongoDB - Challenge Your Understanding

Challenge - 5 Problems

❓ query_result

intermediate

How does embedding affect query results?

Consider a MongoDB collection users where each user document embeds an array of orders. What will be the output of the following query?

db.users.find({ "orders.status": "shipped" })

Choose the correct description of the result.

MongoDB

db.users.find({ "orders.status": "shipped" })

A Returns all users regardless of order status.

B Returns only the orders with status 'shipped' from all users.

C Returns all users who have at least one order with status 'shipped'.

D Returns an error because you cannot query embedded arrays.

💡 Hint

Think about how MongoDB matches documents with embedded arrays.

The query matches user documents where the embedded orders array contains at least one element with status equal to 'shipped'. It returns the whole user document, not just the matching orders.

🧠 Conceptual

intermediate

Why choose referencing over embedding?

In MongoDB, when would referencing documents be a better modeling choice than embedding?

A When you want to avoid using indexes on related fields.

B When related data is large and changes frequently, and you want to avoid duplicating data.

C When you want to store all related data in one document for faster reads.

D When you want to prevent any relationships between collections.

💡 Hint

Think about data size and update frequency.

Referencing is better when related data is large or changes often, so you avoid duplicating data and keep documents smaller. Embedding is better for small, stable related data.

📝 Syntax

advanced

Identify the correct update syntax for embedded documents

Which of the following MongoDB update commands correctly sets the status field to 'delivered' for the order with orderId 123 inside the embedded orders array?

db.users.updateOne({ _id: 1, "orders.orderId": 123 }, ??? )

A { $set: { "orders.$.status": "delivered" } }

B { $set: { "orders.status": "delivered" } }

C { $update: { "orders.$.status": "delivered" } }

D { $set: { "orders[orderId=123].status": "delivered" } }

💡 Hint

Remember how to use the positional operator $ in updates.

The positional operator $ identifies the matched array element in the query filter. Option A correctly uses it to update the status field of the matching order.

❓ optimization

advanced

Optimizing queries with large embedded arrays

You have a products collection where each product document embeds a large array of reviews. Queries filtering by review rating are slow. What is the best way to optimize these queries?

A Move <code>reviews</code> to a separate collection and reference them from <code>products</code>.

B Increase the size limit of documents to hold more reviews.

C Embed more fields inside each review to avoid joins.

D Remove the <code>reviews</code> array and store reviews in a text field.

💡 Hint

Think about document size limits and query performance.

Embedding large arrays can slow queries and hit document size limits. Moving reviews to a separate collection and referencing them improves query speed and scalability.

🔧 Debug

expert

Diagnose the cause of inconsistent data in embedded documents

A MongoDB collection orders embeds customer details inside each order document. After some updates, customer addresses are inconsistent across orders for the same customer. What is the main reason for this inconsistency?

A MongoDB does not support embedded documents for customer data.

B The database automatically synchronizes embedded data, so inconsistency is impossible.

C Referencing customer data inside orders causes inconsistent addresses.

D Embedding customer data causes duplication, so updates to one order do not affect others.

💡 Hint

Consider how embedding duplicates data and update propagation.

Embedding duplicates customer data in each order. If you update the customer address in one order, other orders still have old data, causing inconsistency.

Practice

1. Why is choosing the right data model important in MongoDB?

easy

A. It decides the font used in the database shell

B. It changes the color of the database interface

C. It affects how fast and easy your app can access data

D. It controls the network speed of your internet

Solution

1. Step 1: Understand data model impact

   The data model determines how data is stored and accessed, affecting speed and ease of use.

2. Step 2: Eliminate unrelated options

   Options about colors, fonts, or internet speed do not relate to data modeling.

3. Final Answer:

   It affects how fast and easy your app can access data -> Option C

4. Quick Check:

   Data model affects app speed and ease [OK]

Hint: Data model = app speed and ease [OK]

Common Mistakes:

• Confusing UI features with data modeling
• Thinking data model affects internet speed
• Ignoring performance impact of modeling

2. Which of the following is the correct way to embed an address inside a user document in MongoDB?

easy

A. { name: 'Alice', address: { city: 'NY', zip: '10001' } }

B. { name: 'Alice', address: ['NY', '10001'] }

C. { name: 'Alice', address: 'NY, 10001' }

D. { name: 'Alice', address: ObjectId('abc123') }

Solution

1. Step 1: Identify embedding format

   Embedding means placing a sub-document inside the main document as a nested object.

2. Step 2: Check options for nested object

   { name: 'Alice', address: { city: 'NY', zip: '10001' } } uses a nested object for address, which is correct embedding syntax.

3. Final Answer:

   { name: 'Alice', address: { city: 'NY', zip: '10001' } } -> Option A

4. Quick Check:

   Embedding uses nested objects [OK]

Hint: Embed with nested objects, not arrays or strings [OK]

Common Mistakes:

• Using array instead of object for embedding
• Storing address as a plain string
• Referencing with ObjectId instead of embedding

3. Given the following MongoDB documents, what will be the result of querying for users with embedded orders having product 'Book'?

{ _id: 1, name: 'John', orders: [{ product: 'Book', qty: 2 }, { product: 'Pen', qty: 5 }] }

{ _id: 2, name: 'Jane', orders: [{ product: 'Notebook', qty: 1 }] }

db.users.find({ 'orders.product': 'Book' })

medium

A. [{ _id: 1, name: 'John', orders: [...] }]

B. [{ _id: 2, name: 'Jane', orders: [...] }]

C. []

D. Error: Invalid query

Solution

1. Step 1: Understand query condition

   The query looks for documents where any order's product is 'Book'.

2. Step 2: Match documents with 'Book' product

   Only John has an order with product 'Book', so only his document matches.

3. Final Answer:

   [{ _id: 1, name: 'John', orders: [...] }] -> Option A

4. Quick Check:

   Query matches embedded product 'Book' [OK]

Hint: Query embedded fields with dot notation [OK]

Common Mistakes:

• Assuming query matches documents without 'Book'
• Expecting syntax error from dot notation
• Confusing array matching with string matching

4. You have a user document with an embedded array of comments. You try to update a comment's text but the update does not work. Which is the likely error?

db.users.updateOne(
  { _id: 1, comments.id: 5 },
  { $set: { 'comments.text': 'Updated' } }
)

medium

A. Using updateOne instead of updateMany

B. Syntax error in query filter

C. Incorrect collection name

D. Missing $ positional operator to target the correct array element

Solution

1. Step 1: Analyze update query

   The filter matches the comment with id 5, but the update sets 'comments.text' without specifying which array element.

2. Step 2: Identify missing positional operator

   To update a specific array element, the $ positional operator is needed in the update path: 'comments.$.text'.

3. Final Answer:

   Missing $ positional operator to target the correct array element -> Option D

4. Quick Check:

   Use $ to update matched array element [OK]

Hint: Use $ to update specific array item [OK]

Common Mistakes:

• Forgetting $ in update path for arrays
• Changing updateOne to updateMany unnecessarily
• Assuming collection name or filter syntax is wrong

5. You want to model a blog app where each post has many comments. Comments can be very large and users often read posts without comments. Which modeling choice is best and why?

hard

A. Embed comments inside posts to get all data in one query

B. Store comments in a separate collection and reference posts to avoid large post documents

C. Store comments as strings inside posts to save space

D. Duplicate comments in both posts and a separate collection

Solution

1. Step 1: Analyze data size and access pattern

   Comments are large and often not needed when reading posts, so embedding would make posts heavy.

2. Step 2: Choose referencing for efficiency

   Referencing comments separately keeps post documents small and loads comments only when needed.

3. Final Answer:

   Store comments in a separate collection and reference posts to avoid large post documents -> Option B

4. Quick Check:

   Large optional data = use referencing [OK]

Hint: Large optional data? Use referencing [OK]

Common Mistakes:

• Embedding large optional data causing slow reads
• Storing comments as strings losing structure
• Duplicating data causing inconsistency