Designing One-to-Few Relationships

In this lesson, you will learn how to determine when to embed related data directly within a parent document versus using separate collections for one-to-few relationships.

The "Few" Threshold

In relational database design, we are conditioned to normalize everything into separate tables. However, in document models, a "one-to-few" relationship—where a parent entity is associated with a small, finite, and predictable number of child items—is the ideal candidate for embedding.

If a user has an address book, for instance, and you know a user will never have more than, say, five physical addresses, there is no technical benefit to storing those addresses in a separate collection. By embedding them directly into the User document, you achieve document locality. When you fetch the User, you get all their necessary data in a single disk read, eliminating the need for application-level joins or secondary queries.

Implementation Illustration

Consider a Product document. A product might have a handful of specific technical specifications (e.g., color, weight, material). Instead of creating a Specifications collection, you embed them:

{
  "_id": "prod_123",
  "name": "Mechanical Keyboard",
  "specs": [
    { "key": "Switch Type", "value": "Cherry MX Brown" },
    { "key": "Layout", "value": "TKL" },
    { "key": "Connectivity", "value": "Wired" }
  ]
}

When to Embed

You should choose to embed when:

1. The data size is bounded: The number of items is small and unlikely to grow significantly (e.g., a person's saved payment methods).
2. Access patterns are unified: You almost always need the child data whenever you load the parent.
3. Data is owned by the parent: The child items have no independent utility outside the context of the parent document.

If the "few" items were to grow into a "many" relationship (e.g., a product with thousands of user reviews), embedding would eventually hit the document size limit (often 16MB in many document stores) and create performance bottlenecks during document updates. For one-to-few, however, embedding is the most efficient pattern for both read performance and write atomicity.

Key Takeaway: For relationships that are small, predictable, and tightly coupled, embedding child data directly into the parent document optimizes performance by reducing IO overhead and simplifying data retrieval.