Embedding vs referencing decision in MongoDB - Interactive Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to embed an address document inside a user document.

MongoDB

db.users.insertOne({ name: "Alice", address: [1] })

Drag options to blanks, or click blank then click option'

A{ street: "123 Main St", city: "Springfield" }

B"123 Main St"

C["123 Main St", "Springfield"]

DObjectId("507f1f77bcf86cd799439011")

Attempts:

3 left

💡 Hint

Common Mistakes

Using a string or array instead of an embedded document.

Using an ObjectId which is for referencing, not embedding.

Embedding means placing the address document directly inside the user document as a sub-document.

2fill in blank

medium

Complete the code to reference an address document by its ObjectId in the user document.

MongoDB

db.users.insertOne({ name: "Bob", address_id: [1] })

Drag options to blanks, or click blank then click option'

A{ street: "456 Oak St", city: "Greenville" }

BObjectId("507f1f77bcf86cd799439012")

C"456 Oak St"

D["456 Oak St", "Greenville"]

Attempts:

3 left

💡 Hint

Common Mistakes

Embedding the whole address document instead of referencing.

Using a string or array instead of an ObjectId.

Referencing means storing the ObjectId of the related document instead of embedding the whole document.

3fill in blank

hard

Fix the error in the referencing code to correctly store the address reference.

MongoDB

db.users.insertOne({ name: "Carol", address_id: [1] })

Drag options to blanks, or click blank then click option'

A["507f1f77bcf86cd799439013"]

B"507f1f77bcf86cd799439013"

C{ _id: "507f1f77bcf86cd799439013" }

DObjectId("507f1f77bcf86cd799439013")

Attempts:

3 left

💡 Hint

Common Mistakes

Using a plain string instead of ObjectId().

Using an array or object instead of ObjectId.

The address_id field must be an ObjectId type, not a string or array.

4fill in blank

hard

Fill both blanks to embed multiple phone numbers inside a user document.

MongoDB

db.users.insertOne({ name: "Dave", phones: [1] })
// Each phone is a [2]

Drag options to blanks, or click blank then click option'

A[{ type: "home", number: "123-4567" }, { type: "work", number: "987-6543" }]

B"string"

Cobject

D["123-4567", "987-6543"]

Attempts:

3 left

💡 Hint

Common Mistakes

Using an array of strings instead of objects.

Saying each phone is a string instead of an object.

Phones are embedded as an array of objects, each object representing a phone with type and number.

5fill in blank

hard

Fill all three blanks to create a referencing pattern with user and address collections.

MongoDB

const user = {
  name: "Eve",
  address_id: [1]
};

const address = {
  _id: [2],
  street: "789 Pine St",
  city: [3]
};

Drag options to blanks, or click blank then click option'

AObjectId("507f1f77bcf86cd799439014")

B"Springfield"

D"Greenville"

Attempts:

3 left

💡 Hint

Common Mistakes

Using strings instead of ObjectId for IDs.

Mixing up city names or using ObjectId for city.

The user references the address by ObjectId. The address document has the same ObjectId and a city name string.

Practice

1. Which scenario is best suited for embedding related data in MongoDB?

easy

A. Storing a user's profile and their list of addresses when addresses are few and rarely shared.

B. Storing product details and linking to multiple categories by ID.

C. Storing large documents that are frequently updated independently.

D. Storing shared tags used by many blog posts.

Solution

1. Step 1: Understand embedding use case

   Embedding is best when related data is small and tightly coupled, like a user's addresses.

2. Step 2: Analyze options for embedding

   Storing a user's profile and their list of addresses when addresses are few and rarely shared fits because addresses are few and not shared, so embedding improves read speed.

3. Final Answer:

   Storing a user's profile and their list of addresses when addresses are few and rarely shared. -> Option A

4. Quick Check:

   Embedding = small, tightly related data [OK]

Hint: Embed when data is small and tightly linked [OK]

Common Mistakes:

• Embedding large or shared data causing duplication
• Referencing small, simple data unnecessarily

2. Which of the following is the correct way to reference a document in MongoDB?

easy

A. { "author_id": ObjectId("507f1f77bcf86cd799439011") }

B. { "author": { "$ref": "users", "$id": ObjectId("507f1f77bcf86cd799439011") } }

C. { "author": ObjectId("507f1f77bcf86cd799439011") }

D. { "author": "507f1f77bcf86cd799439011" }

Solution

1. Step 1: Identify referencing syntax

   Referencing stores the related document's ID as a field, usually named with _id suffix.

2. Step 2: Check options for correct ID reference

   { "author_id": ObjectId("507f1f77bcf86cd799439011") } correctly stores the ObjectId with a clear field name author_id.

3. Final Answer:

   { "author_id": ObjectId("507f1f77bcf86cd799439011") } -> Option A

4. Quick Check:

   Reference = store related document's ID [OK]

Hint: Reference by storing ObjectId in a field ending with _id [OK]

Common Mistakes:

• Using string instead of ObjectId for references
• Using $ref and $id without DBRef context
• Embedding full document instead of referencing

3. Given a MongoDB collection orders where each order embeds a small array of items, what is the expected result of querying an order by ID?

medium

A. Only the order document without any items data.

B. An error because embedded arrays cannot be queried.

C. The order document with all embedded items included in the result.

D. A list of item documents from a separate collection.

Solution

1. Step 1: Understand embedding query behavior

   When data is embedded, querying the parent document returns all embedded data inside it.

2. Step 2: Analyze query result for embedded items

   Querying by order ID returns the order document including the embedded items array.

3. Final Answer:

   The order document with all embedded items included in the result. -> Option C

4. Quick Check:

   Embedding returns full embedded data [OK]

Hint: Embedded data returns inside parent document query [OK]

Common Mistakes:

• Expecting separate documents for embedded data
• Thinking embedded arrays cause query errors
• Confusing referencing with embedding results

4. You have a MongoDB schema where user documents embed an array of posts. You notice performance issues when updating posts frequently. What is the likely cause and fix?

medium

A. Indexing embedded arrays causes slow updates; remove indexes.

B. Referencing posts causes slow updates; embed posts instead.

C. Using ObjectId for posts causes slow updates; use strings instead.

D. Embedding large arrays causes slow updates; switch to referencing posts separately.

Solution

1. Step 1: Identify embedding impact on updates

   Embedding large or frequently updated arrays causes the whole document to be rewritten, slowing updates.

2. Step 2: Choose referencing to improve update performance

   Referencing posts separately allows updating posts without rewriting the entire user document.

3. Final Answer:

   Embedding large arrays causes slow updates; switch to referencing posts separately. -> Option D

4. Quick Check:

   Large/frequent updates = use referencing [OK]

Hint: Large, frequently updated data? Use referencing [OK]

Common Mistakes:

• Embedding large arrays despite frequent updates
• Ignoring update performance impact
• Misunderstanding ObjectId role in updates

5. You are designing a MongoDB schema for a blogging platform. Each blog post has many comments, and comments can be edited or deleted independently. Also, comments can be very large in number. What is the best design choice?

hard

A. Embed all comments inside each blog post document.

B. Reference comments in a separate collection linked by post ID.

C. Embed only the first 10 comments and reference the rest.

D. Store comments as a JSON string inside the blog post.

Solution

1. Step 1: Analyze comment characteristics

   Comments are numerous, large, and updated independently, so embedding would cause large documents and slow updates.

2. Step 2: Choose referencing for scalability and independent updates

   Referencing comments in a separate collection allows efficient updates and avoids large blog post documents.

3. Final Answer:

   Reference comments in a separate collection linked by post ID. -> Option B

4. Quick Check:

   Large, independent data = referencing [OK]

Hint: Large, independent data? Reference separately [OK]

Common Mistakes:

• Embedding large, frequently updated arrays
• Mixing embedding and referencing without clear rules
• Storing JSON strings instead of structured data