Data Modeling and Schema Design

Data modeling in MongoDB is fundamentally different from relational design. Instead of normalizing everything into separate tables, you decide — for every relationship — whether to embed related data or reference it in another collection.

1. Embedding vs Referencing

2. One-to-Few (Embedding)

{
  "_id": ObjectId("..."),
  "name": "Priya Mehta",
  "addresses": [
    { "type": "home", "city": "Jaipur" },
    { "type": "work", "city": "Gurgaon" }
  ]
}

3. One-to-Many (Referencing)

When the "many" side can grow large — like orders for a customer — reference by storing the parent's _id in the child document.

// customers collection
{ "_id": ObjectId("cust1"), "name": "Vikram Rao" }

// orders collection
{ "_id": ObjectId("ord1"), "customerId": ObjectId("cust1"), "total": 4599 }
{ "_id": ObjectId("ord2"), "customerId": ObjectId("cust1"), "total": 1299 }

4. Many-to-Many

Many-to-many relationships (e.g., students and courses) are typically modeled by referencing arrays of IDs on either or both sides.

// students collection
{ "_id": ObjectId("s1"), "name": "Ishaan", "courseIds": [ObjectId("c1"), ObjectId("c2")] }

// courses collection
{ "_id": ObjectId("c1"), "title": "Databases 101", "studentIds": [ObjectId("s1")] }

5. Hybrid Approach

Real-world schemas often mix both — embedding a summary while referencing the full record.

{
  "_id": ObjectId("ord3"),
  "customer": { "id": ObjectId("cust1"), "name": "Vikram Rao" }, // embedded summary
  "items": [ { "productId": ObjectId("p1"), "qty": 2 } ],        // referenced products
  "total": 3499
}

6. Data Modeling Checklist

• ✅ Identify access patterns before designing the schema
• ✅ Embed for one-to-few, tightly coupled data
• ✅ Reference for one-to-many at scale and many-to-many
• ✅ Watch out for unbounded array growth
• ✅ Consider hybrid embedding + referencing where appropriate