Why document design matters in MongoDB - Challenge Your Understanding

Challenge - 5 Problems

❓ query_result

intermediate

How does embedding affect query speed?

Consider a MongoDB collection users where each user document embeds an array of orders. Which query will generally be faster to retrieve all orders for a single user?

MongoDB

db.users.findOne({user_id: 123}, {orders: 1})

A Querying the <code>users</code> collection with embedded <code>orders</code> returns all orders in one read.

B Querying <code>users</code> without embedding orders is faster for all cases.

C Using a join operation between <code>users</code> and <code>orders</code> collections is faster.

D Querying a separate <code>orders</code> collection with a user_id filter is always faster.

💡 Hint

Think about how embedding data reduces the need for multiple queries.

Embedding related data like orders inside a user document allows MongoDB to fetch all needed data in a single read, improving query speed.

🧠 Conceptual

intermediate

Why avoid large documents in MongoDB?

What is a main reason to avoid very large documents in MongoDB?

A MongoDB does not support documents larger than 1 KB.

B Large documents automatically split into multiple collections.

C Large documents can slow down read and write operations due to size limits and memory usage.

D Large documents improve query speed by storing more data in one place.

💡 Hint

Consider how document size affects performance and limits.

MongoDB has a document size limit (16MB), and very large documents can slow down operations and increase memory use.

📝 Syntax

advanced

Identify the correct schema design for referencing

Which MongoDB document design correctly references another collection?

MongoDB

User document referencing an Address document

A {"name": "Alice", "address": {"street": "Main St", "city": "Town"}}

B {"name": "Alice", "address": "507f1f77bcf86cd799439011"}

C {"name": "Alice", "address": ObjectId("507f1f77bcf86cd799439011")}

D {"name": "Alice", "address_id": ObjectId("507f1f77bcf86cd799439011")}

💡 Hint

Referencing uses ObjectId type fields to link documents.

Option D correctly uses an ObjectId field to reference another document. Option D embeds the address, not referencing. Option D uses ObjectId but inside an object, which is invalid. Option D uses a string instead of ObjectId.

🔧 Debug

advanced

Why does this query return no results?

Given a collection products where each document embeds an array tags, why does this query return no results?

db.products.find({tags: "electronics"})

A Because the field name <code>tags</code> is misspelled in the query.

B Because <code>tags</code> is an array, the query should use <code>{tags: {$in: ["electronics"]}}</code> to match elements.

C Because the query syntax is invalid and causes an error.

D Because the <code>tags</code> field does not exist in any document.

💡 Hint

Think about how MongoDB matches array fields in queries.

MongoDB matches array fields by checking if the value is an element of the array. The query {tags: "electronics"} matches documents where tags array contains exactly "electronics" as an element, so it should work. But if the array contains objects or complex types, $in is safer. However, the main reason is that if the array contains objects, the query won't match a string. Using $in ensures matching any element in the array.

🧠 Conceptual

expert

Impact of document design on scaling

How does document design affect horizontal scaling in MongoDB sharded clusters?

A Poor document design with large embedded arrays can cause uneven shard key distribution and hotspotting.

B Document design does not affect sharding; only shard keys matter.

C Referencing documents across shards automatically balances load evenly.

D Embedding all data in one document always improves scaling by reducing network calls.

💡 Hint

Consider how document size and structure affect shard key distribution and performance.

Large embedded arrays can cause documents to be large and unevenly distributed, leading to hotspots on certain shards. Good document design helps distribute data evenly and improves scaling.

Practice

1. Why is good document design important in MongoDB?

easy

A. It groups related data together for faster access.

B. It makes the database use more disk space.

C. It forces all data to be stored in separate collections.

D. It prevents any data from being updated.

Solution

1. Step 1: Understand document design purpose

   Good document design groups related data to reduce the number of database lookups.

2. Step 2: Identify the benefit of grouping data

   Grouping related data together makes data access faster and simpler for the application.

3. Final Answer:

   It groups related data together for faster access. -> Option A

4. Quick Check:

   Good design = grouped data = faster access [OK]

Hint: Good design groups related data for speed [OK]

Common Mistakes:

• Thinking design increases disk space unnecessarily
• Believing all data must be in separate collections
• Assuming design stops data updates

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

easy

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

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

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

D. { name: 'Alice', address: null }

Solution

1. Step 1: Recognize embedded document syntax

   Embedding means putting a document inside another document as a nested object.

2. Step 2: Identify correct nested object format

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

3. Final Answer:

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

4. Quick Check:

   Embedded document = nested object = { name: 'Alice', address: { city: 'NY', zip: '10001' } } [OK]

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

Common Mistakes:

• Using arrays instead of objects for embedded data
• Storing address as a plain string
• Leaving embedded fields null without reason

3. Given this user document:
{ _id: 1, name: 'Bob', orders: [{ id: 101, total: 50 }, { id: 102, total: 30 }] }
What will be the result of the query db.users.findOne({ _id: 1 })?

medium

A. null

B. { _id: 1, name: 'Bob' }

C. { _id: 1, name: 'Bob', orders: [{ id: 101, total: 50 }, { id: 102, total: 30 }] }

D. SyntaxError

Solution

1. Step 1: Understand findOne query behavior

   The findOne query returns the entire document matching the filter {_id: 1}.

2. Step 2: Check document structure

   The document includes the orders array embedded inside, so the full document is returned.

3. Final Answer:

   { _id: 1, name: 'Bob', orders: [{ id: 101, total: 50 }, { id: 102, total: 30 }] } -> Option C

4. Quick Check:

   findOne returns full document = { _id: 1, name: 'Bob', orders: [{ id: 101, total: 50 }, { id: 102, total: 30 }] } [OK]

Hint: findOne returns full matching document [OK]

Common Mistakes:

• Expecting only part of the document returned
• Thinking query returns null if embedded arrays exist
• Confusing syntax errors with valid queries

4. You want to embed a list of comments inside a blog post document, but your code throws an error. Which is the likely cause?
{ title: 'Post', comments: 'Great post!' }

medium

A. Comments should be an array of objects, not a string.

B. Title field cannot be a string.

C. MongoDB does not allow embedding arrays.

D. The document must have an _id field.

Solution

1. Step 1: Check the comments field type

   Comments are given as a string, but embedding multiple comments requires an array of objects.

2. Step 2: Understand embedding requirements

   Embedding multiple related items means using an array of objects, not a single string.

3. Final Answer:

   Comments should be an array of objects, not a string. -> Option A

4. Quick Check:

   Embed lists as arrays, not strings [OK]

Hint: Embed lists as arrays of objects, not strings [OK]

Common Mistakes:

• Using string instead of array for multiple items
• Thinking title cannot be string
• Believing MongoDB forbids arrays
• Assuming _id is always required manually

5. You have a product catalog where each product has many reviews. Reviews can grow large over time. What is the best document design to handle this efficiently?

hard

A. Embed all reviews inside each product document.

B. Duplicate product data inside each review document.

C. Store only the first review inside the product document.

D. Store reviews in a separate collection linked by product ID.

Solution

1. Step 1: Consider document size limits and growth

   Embedding many reviews inside a product can make the document very large and slow to update.

2. Step 2: Choose design for large growing data

   Storing reviews separately and linking by product ID keeps product documents small and queries efficient.

3. Final Answer:

   Store reviews in a separate collection linked by product ID. -> Option D

4. Quick Check:

   Large growing data = separate collection [OK]

Hint: Large growing lists? Use separate collections [OK]

Common Mistakes:

• Embedding large growing arrays inside documents
• Storing only partial data inside main document
• Duplicating product data unnecessarily