MongoDB Embedding vs Referencing | Denormalization

# CHAPTER 14

Embedding vs Referencing Documents #

1. Introduction #

2. Learning Objectives #

• Define Embedding (Denormalization).

• Define Referencing (Normalization).

• Identify the pros and cons of both architectures.

• Understand the problem of "Data Duplication" and "Update Anomalies".

• Make confident architectural decisions for real-world schemas.

3. The Embedded Approach (Denormalization) #

// Collection: orders
{
  "_id": 101,
  "user": { "name": "John Doe", "email": "john@example.com" }, // Embedded!
  "product": { "id": 55, "name": "Laptop", "price": 999 },     // Embedded!
  "total": 999
}

Pros:

• Blazing Fast Reads: To display an Order Receipt page, the backend executes exactly 1 query. All the data is instantly available.

Cons:

• Data Duplication: If John places 50 separate orders, his name and email are duplicated 50 times across 50 different documents.

• Update Anomalies: If John changes his email address, you cannot just update a single users document. You must write a complex updateMany() query to hunt down and update all 50 of his historical order documents!

4. The Referenced Approach (Normalization) #

// Collection: users
{ "_id": ObjectId("User_John"), "name": "John Doe", "email": "john@example.com" }

// Collection: products
{ "_id": ObjectId("Prod_Laptop"), "name": "Laptop", "price": 999 }

// Collection: orders
{
  "_id": 101,
  "user_id": ObjectId("User_John"),      // Reference!
  "product_id": ObjectId("Prod_Laptop"), // Reference!
  "total": 999
}

Pros:

• Clean Updates: If John changes his email, you run one simple updateOne() on the users collection. The orders collection doesn't need to change because it just points to John's ID.

Cons:

• Slow Reads: To display the Order Receipt page, the backend must execute 3 separate queries (Get Order, Get User, Get Product). Network latency increases.

5. The Hybrid Approach (The Industry Standard) #

// Collection: orders
{
  "_id": 101,
  "user_id": ObjectId("User_John"), 
  // We EMBED the snapshot of the price at the time of checkout!
  "snapshot_product": { 
      "id": ObjectId("Prod_Laptop"), 
      "name": "Laptop", 
      "price_at_checkout": 999 
  }
}

Why this is brilliant: If the live Laptop price increases to $1200 tomorrow, John's historical receipt must still say $999. Embedding the snapshot preserves historical accuracy while referencing maintains overall database sanity!

6. The Decision Matrix (When to use which?) #

1. 1. Does the data grow infinitely? (e.g., Server Logs).

1. 2. Is the data accessed together 99% of the time? (e.g., A blog post and its title).

1. 3. Does the data change constantly? (e.g., A live stock price).

7. Mini Project: Ecommerce Product System #

• Images: There are only 5. They are only ever viewed when looking at the product. They don't change often. -> EMBED an array of URLs.

• Category: A category name ("Electronics") might change to ("Tech"). Millions of products share this category. -> REFERENCE the Category ID.

{
  "_id": ObjectId("..."),
  "name": "Wireless Mouse",
  "category_id": ObjectId("Cat_Electronics"), // Referenced
  "images": [ // Embedded
    "url.com/img1.jpg", 
    "url.com/img2.jpg"
  ]
}

8. Common Mistakes #

• Fear of Duplication: Developers coming from strict SQL backgrounds are terrified of data duplication. In NoSQL, duplicating a user's username across 100 comments to avoid doing a JOIN is highly encouraged. Storage is cheap; CPU time is expensive.

9. Best Practices #

• Analyze the Read/Write Ratio: If a field is read 10,000 times a second but updated once a year (like a username), embed and duplicate it everywhere. The massive speed boost on Reads heavily outweighs the annoyance of running an updateMany() once a year.

10. Exercises #

1. 1. What is the MongoDB term for putting all related data directly inside a single document (Denormalization)?

1. 2. If a document embeds an array of data that grows by 100 items per minute, what strict MongoDB limitation will the document eventually hit and crash against?

11. MongoDB Challenges #

12. MCQ Quiz with Answers #

13. Interview Questions #

• Q: You are tasked with migrating a highly normalized MySQL database to MongoDB. The Lead Engineer suggests keeping all 50 tables exactly as they are and just using ObjectIds to link them. Provide an architectural argument against this approach.

• Q: Explain the Decision Matrix for Embedding vs. Referencing. What three questions should an architect ask themselves before finalizing a schema?

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #