Part 2—Analysis: Designing for Access Patterns, Not Tables 

In the relational world, analysis usually starts with an ER diagram. We ask questions like: 

• What are the entities? 
• How are they related? 
• What are the primary and foreign keys? 
• How do we normalize this model?

This approach makes perfect sense in SQL because the database is designed to store relationships cleanly and reconstruct them later using joins.  

But when we carry this same analysis approach into MongoDB, we get into trouble. Why? Because MongoDB isn’t optimized for reconstructing relationships, it’s optimized for storing complete units of data that are read together.  So before modeling anything in a document database, the questions must change. 

Relational Analysis vs Document Analysis — The Shift 

Relational analysis is about data integrity and flexibility for any query. 
Document analysis is about speed and efficiency for common queries. 

This is why MongoDB schema design must start from how the application uses the data, not how the entities are conceptually related.

Understanding Access Patterns (The Core of Document Design) 

Before writing a schema in MongoDB, you should answer: 

• Which user flows read this data? 
• What does the UI need in one shot? 
• What is the most common read path? 
• Do these pieces of data live and change together? 
• Do we prioritize read speed or update speed for this flow?

If 80–90% of the time a UI/API loads the same combined view, that’s a strong candidate for embedding. 

 Using the “Order Details Screen” as the Running Example 

Let’s reuse the same scenario from Part 1: 

When a user opens the Order Details page, we should display the current active order. 

Relational thinking would say: 

• Orders → Table 
• Order Items → Table 
• Products → Table 
• Addresses → Table 
• And we’ll join them later

Document thinking asks instead: 

• What does the Order Details API need in a single response? 
• Can we store that together in one document so the UI gets it in one read? 

Since 99% of the time the UI wants the whole order, MongoDB prefers:

 

Order (document) 
 |- Basic details 
 |- Items (embedded) 
 |- Product snapshot (embedded) 
 |- Shipping address (embedded) 
 

Why? Because the access pattern is unified. The UI always reads this data together, so the DB should store it together. 

Key Analysis Principle: “Read → Model, Not Model → Read” 

In SQL, we model first and read later. 
In MongoDB, we analyse reads first and model after. 

This one principle prevents: 

• Overuse of $lookup 
• Relational schemas inside Mongo 
• Poor read performance 
• Overcomplicated application code 

 
But What About Updates? (The Common Fear) 

In relational design, we normalize to avoid duplication. 
In MongoDB, we accept a bit of duplication to make reads fast and simple. 

The question shifts from: 

• “How do I prevent duplication?” (Relational) 

to 

• “Is this duplication acceptable for faster reads?” (Document) 

This is why analysis is so critical: we need to know which data changes often and which doesn’t. 

Example: 

Key Takeaways 

• MongoDB schema design must begin with access pattern analysis, not relationship mapping 
• If data is read together, it should usually be stored together 
• Embedding is not “denormalization gone wild”; it is intentional locality 
• The mindset shift in the analysis phase prevents most modeling mistakes later