LearnAI ToolsCareerPractice BuildsPlayContact
Lesson 2117 min read

Modeling One-to-Many Relationships

Apply the embedding vs referencing decision to the most common relationship shape — one document related to many others.

Three Flavors of One-to-Many

Not all one-to-many relationships are alike — the right modeling choice depends heavily on how large the "many" side can realistically grow.

One-to-Few: Embed

When the "many" side has a small, naturally bounded count — a person's addresses, a product's variants — embedding as an array is the simplest, most efficient choice.

{
  "_id": "u1",
  "name": "Ada Lovelace",
  "addresses": [
    { "type": "home", "city": "London" },
    { "type": "work", "city": "Manchester" }
  ]
}

One-to-Many: Reference

When the "many" side can grow into the hundreds or more — a user's orders — reference from the "one" side isn't practical to embed; store the relationship on the "many" side instead, pointing back to its parent.

// users
{ "_id": "u1", "name": "Ada Lovelace" }


// orders — each order references its user
{ "_id": "o1", "userId": "u1", "total": 65 }
{ "_id": "o2", "userId": "u1", "total": 120 }
db.orders.find({ userId: "u1" }); // fetch all of a user's orders

One-to-Squillions: Reference from the "Many" Side

For truly enormous "many" sides — a popular server's millions of log entries, referencing a single host — even storing the relationship is done exclusively on the many side, since the "one" side could never practically hold a list of that many ids.

// hosts
{ "_id": "host1", "name": "web-server-01" }


// logs — potentially millions of these, each referencing its host
{ "_id": "log1", "hostId": "host1", "message": "Request completed", "timestamp": "..." }
The Pattern in Common

Notice that as the "many" side grows, the relationship consistently moves toward being stored on the many side, referencing back to the one — never the reverse.

Common Beginner Mistakes

Embedding an array of references on the "one" side for a large "many"

A "user" document holding an ever-growing array of orderIds still risks unbounded document growth — reference from the many side (orders storing userId) instead.

Treating every one-to-many relationship the same way

A person's addresses and a user's server logs have wildly different scale characteristics — always consider the realistic size of the "many" side before choosing a pattern.

FAQs

Rough guidelines: dozens or fewer favors embedding; hundreds to low thousands favors referencing from the many side; anything unbounded or in the millions strongly favors referencing exclusively from the many side.

Yes — a common pattern embeds, say, the 5 most recent orders directly on a user for fast display, while the full order history lives in a separate, queryable collection.

Summary

The right one-to-many pattern depends on how large the "many" side can grow — few favors embedding, many and beyond favors referencing from the many side. Next, you'll look at modeling many-to-many relationships.

Next Lesson →

Modeling Many-to-Many Relationships