MongoDB Schema Design | One-to-One, One-to-Many Relationships

# CHAPTER 13

Relationships and Schema Design #

1. Introduction #

2. Learning Objectives #

• Understand the MongoDB philosophy of "Application Driven Design".

• Model One-to-One (1:1) relationships.

• Model One-to-Many (1:N) relationships.

• Model Many-to-Many (N:M) relationships.

• Understand when to embed data vs. when to link data.

3. Application Driven Design #

The Golden Rule of MongoDB: Data that is accessed together, should be stored together. If your mobile app screen shows a User Profile AND their Address at the exact same time, you should store them in the exact same document.

4. One-to-One (1:1) Relationships #

How to model it: You almost *always* Embed the data directly inside the main document as a nested object.

// A User document with an Embedded 1:1 Badge relationship
{
  "_id": ObjectId("..."),
  "name": "Sarah Connor",
  "email": "sarah@example.com",
  "badge": {
    "badge_number": "A-1234",
    "access_level": 5
  }
}

*(Retrieving Sarah's data requires 1 query. In SQL, it would require 2 queries or a JOIN).*

5. One-to-Many (1:N) Relationships #

How to model it: You Embed the data as an Array of Objects.

// A User document with an Embedded 1:N Addresses relationship
{
  "_id": ObjectId("..."),
  "name": "John Smith",
  "addresses": [
    { "type": "Home", "city": "Seattle", "zip": "98101" },
    { "type": "Office", "city": "Redmond", "zip": "98052" }
  ]
}

6. The "One-to-Squillions" (1:N) Problem #

How to model it: If the array is unbounded (can grow infinitely), you MUST switch to Referencing (Linking). You put the Citizens in their own collection, and put the City's ObjectId on them (exactly like a SQL Foreign Key).

// The City Document (Collection: cities)
{ "_id": ObjectId("City_NYC"), "name": "New York" }

// The Citizen Document (Collection: citizens)
{ 
  "_id": ObjectId("User_John"), 
  "name": "John",
  "city_id": ObjectId("City_NYC") // The Reference Link!
}

7. Many-to-Many (N:M) Relationships #

How to model it: You use Two-Way Referencing (Arrays of ObjectIds). Unlike SQL, which requires a complex third "Pivot Table", MongoDB just stores an array of IDs on both sides!

// Student Document
{
  "_id": ObjectId("Student_Bob"),
  "name": "Bob",
  "enrolled_courses": [ ObjectId("Course_Math"), ObjectId("Course_Art") ]
}

// Course Document
{
  "_id": ObjectId("Course_Math"),
  "title": "Calculus 101",
  "enrolled_students": [ ObjectId("Student_Bob"), ObjectId("Student_Alice") ]
}

8. Common Mistakes #

• Applying SQL Normalization to MongoDB: The worst schema you can design in MongoDB is one with 20 different collections linked by ObjectIds that requires you to do 5 queries just to load a webpage. Embrace embedding. Data duplication (Denormalization) is highly acceptable in MongoDB if it speeds up read performance!

9. Best Practices #

• Favor Reads over Writes: Usually, data is read 1,000 times more often than it is written (Think of a Tweet: written once, read by millions). Therefore, design your documents so that the Read query is instantaneous, even if it makes the Update query slightly more complex.

10. Exercises #

1. 1. What is the MongoDB Golden Rule of schema design regarding how data is accessed?

1. 2. If a blog post has 3 "Tags" (e.g., "tech", "nosql", "coding"), should you put the Tags in their own collection and link them, or embed them as an array of strings directly in the blog post document?

11. MongoDB Challenges #

{
  "_id": 1,
  "title": "Learning NoSQL",
  "author": { "name": "Alice", "country": "UK" },
  "reviews": [
    { "user": "Bob", "stars": 5 },
    { "user": "Charlie", "stars": 4 }
  ]
}

12. MCQ Quiz with Answers #

13. Interview Questions #

• Q: Explain the core philosophical difference between SQL Database Schema design (Normalization) and MongoDB Schema design (Application Driven Design).

• Q: Describe a scenario where data duplication (Denormalization) is considered an architectural best practice in MongoDB.

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #