Normalization vs denormalization default in MongoDB - Visual Side-by-Side Comparison

Concept Flow - Normalization vs denormalization default

Start: Data Storage

↓

Normalization

↓

Separate Collections

↓

Use References

↓

Join Data at Query

↓

More Queries

↓

Less Data Duplication

↓

Complex Updates

↓

End

This flow shows the choice between normalization and denormalization in MongoDB, highlighting how data is stored, queried, and updated differently.

Execution Sample

MongoDB

db.orders.insertOne({
  _id: 1,
  customer: { _id: 101, name: "Alice" },
  items: [ { product: "Pen", qty: 3 } ]
})

Insert an order document embedding customer info and items, showing denormalization by embedding related data.

Execution Table

Step	Action	Data Structure	Query Type	Effect
1	Insert order with embedded customer	Order document with embedded customer object	Insert	Data stored in one document, no references
2	Query order by _id	Single document with embedded data	FindOne	Single query returns order and customer info
3	Update customer name	Customer data inside order document	Update	Must update all orders embedding this customer
4	Insert order with customer reference	Order document with customer _id reference	Insert	Data split across collections
5	Query order and join customer	Order references customer collection	Aggregate with $lookup	Multiple queries combined, more complex
6	Update customer name in customer collection	Customer data centralized	Update	Single update affects all orders referencing customer
7	End	-	-	Shows trade-offs between normalization and denormalization

💡 Process ends after showing key steps of data insertion, querying, and updating in both models.

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 4	After Step 6	Final
Order Document	Empty	{_id:1, customer:{_id:101, name:"Alice"}, items:[...]}	{_id:1, customer:{_id:101, name:"Alice B."}, items:[...]}	{_id:2, customer_id:101, items:[...]}	{_id:2, customer_id:101, items:[...]}	Shows embedded and referenced forms
Customer Data	Empty	Embedded in order	Embedded updated in all orders	Separate collection	Updated once centrally	Centralized customer data

Key Moments - 3 Insights

Why do we need to update multiple documents when customer data is embedded?

Because in denormalization, customer info is copied inside each order document (see execution_table step 3), so each order must be updated to keep data consistent.

How does referencing customer data simplify updates?

Referencing stores customer data in one place (execution_table step 6), so updating customer info once updates all related orders automatically.

Why does querying become more complex with normalization?

Because data is split across collections and requires joins or $lookup (execution_table step 5), needing multiple queries combined.

Visual Quiz - 3 Questions

Look at the execution_table at step 2, what data is returned by the query?

A Order data with embedded customer info

B Customer data only

C Only order data without customer info

D No data returned

💡 Hint

Check the 'Data Structure' column at step 2 showing embedded customer object.

At which step does updating customer data require changing multiple documents?

A Step 1

B Step 6

C Step 3

D Step 5

💡 Hint

Look at 'Effect' column in step 3 about updating embedded customer data.

If we embed customer data in orders, how does it affect query complexity?

A Queries require more joins

B Queries become simpler with fewer joins

C Queries need aggregation pipelines

D Queries cannot find customer data

💡 Hint

Refer to execution_table step 2 vs step 5 comparing embedded vs referenced queries.

Concept Snapshot

Normalization vs Denormalization in MongoDB:
- Normalization: store related data in separate collections using references.
- Denormalization: embed related data inside documents.
- Normalization reduces data duplication but needs joins ($lookup).
- Denormalization simplifies queries but duplicates data.
- Choose based on update frequency and query needs.

Full Transcript

This visual execution shows how MongoDB handles data with normalization and denormalization. Normalization stores related data in separate collections and uses references, requiring joins during queries but simplifying updates. Denormalization embeds related data inside documents, making queries simpler but requiring updates in multiple places. The execution table traces inserting orders with embedded customer data versus referencing customer data, querying them, and updating customer info. Variable tracking shows how order and customer data change. Key moments clarify why updates differ and how query complexity changes. The quiz tests understanding of these trade-offs. This helps beginners see practical effects of data modeling choices in MongoDB.