Hoe ontwerp je schema's in MongoDB?

Question

Accepted Answer

MongoDB-schemaontwerp concentreert zich op een sleutelkeuze: **embedding** (gerelateerde gegevens opslaan in een document) versus **referencing** (gerelateerde gegevens opslaan in aparte documenten/collecties met verwijzingen). Anders dan SQL's normalize-by-default, optimaliseert MongoDB-ontwerp voor hoe de gegevens *worden gebruikt*.

## Embedding — gerelateerde gegevens samen opslaan

```js
// embed related data within the document
{
  _id: ObjectId("..."),
  name: "Ann",
  address: { city: "NY", zip: "10001" },        // embedded sub-document
  orders: [                                      // embedded array of orders
    { product: "Phone", amount: 999 },
    { product: "Case", amount: 20 }
  ]
}
// → ONE query gets the user AND their address AND orders (no joins)
```

**Embedding** houdt gerelateerde gegevens in één document — lees alles in één query (snel, geen joins). Goed voor gegevens die samen worden gebruikt en "contains" relaties.

## Referencing — aparte documenten koppelen

```js
// store a reference (id) to a document in another collection
{ _id: ObjectId("u1"), name: "Ann" }                          // users collection
{ _id: ObjectId("o1"), userId: ObjectId("u1"), product: "Phone" } // orders collection
// → query orders by userId; use $lookup to join when needed
```

**Referencing** slaat gegevens apart op en koppelt via id (zoals een foreign key) — query apart of voeg samen met `$lookup`.

## Wanneer embed je versus reference je

```text
EMBED when:
  ✓ data is accessed TOGETHER (read the parent → you want the children)
  ✓ a "contains"/ownership relationship (address, order line items)
  ✓ the embedded data is bounded (not unboundedly growing)
  ✓ one-to-few relationships

REFERENCE when:
  ✓ data is large or grows UNBOUNDEDLY (avoid huge documents — 16MB doc limit!)
  ✓ data is accessed/updated INDEPENDENTLY
  ✓ many-to-many or one-to-many with many
  ✓ the same data is shared/referenced by many documents (avoid duplication)
```

## Ontwerp voor toegangspatronen (het kernprincipe)

```text
MongoDB schema design is driven by HOW YOU QUERY the data, not pure normalization:
  → Structure data so common queries are efficient (often a single document read).
  → "Data that is accessed together should be stored together."
  → This may mean DENORMALIZING (some duplication) for read efficiency — acceptable
    in MongoDB, traded against update complexity.
```

## Waarom het belangrijk is

Schemaontwerp is kritiek belangrijk in MongoDB — het verschilt van en is wellicht belangrijker dan in SQL, omdat MongoDB's flexibele documentmodel je keuzes geeft die aanzienlijk van invloed zijn op prestaties en onderhoudbaarheid. Het begrijpen ervan is essentieel voor het bouwen van effectieve MongoDB-toepassingen.

De centrale keuze — **embedding versus referencing** — is de definiërende MongoDB-ontwerrkeuze: **embedding** (gerelateerde gegevens in een document opslaan) maakt snelle enkelvoudige-query-lezingen van gerelateerde gegevens mogelijk (geen joins) en past bij gegevens die samen worden gebruikt en "contains" relaties, terwijl **referencing** (aparte documenten koppelen via id) geschikt is voor grote/onbegrensd groeiende gegevens, onafhankelijk gebruikte gegevens en gedeelde/veel-op-veel relaties.

Begrijpen **wanneer je elk gebruikt** (embed voor begrensd, samen-gebruikt, eigendomsgegeven; reference voor groot/groeiend, onafhankelijk, gedeeld of veel-relaties — en wees je bewust van MongoDB's 16MB-documentgroot-limiet) is de kernvaardigheid.

Het allerbelangrijkste is het begrijpen van het stuurprincipe — **ontwerp voor toegangspatronen** (structureer gegevens rond *hoe je ze opvraagt*, zodat veel voorkomende query's efficiënt zijn, vaak een enkelvoudige documentlezeling, in plaats van normaliseren als standaard zoals SQL) — dit is wat goed MongoDB-schemaontwerp onderscheidt.

Dit kan betekenen dat je **denormalisatie** (duplicatie) accepteert voor leesfefficiëntie, een afweging tegen updatecomplexiteit die aanvaardbaar en vaak correct is in MongoDB.

Omdat schemaontwerp MongoDB-toepassingsprestaties en onderhoudbaarheid diepgaand beïnvloedt (een slechte embed/reference-keuze veroorzaakt trage query's, enorme documenten of updatecomplexiteit), en omdat de toegangspatroon-gedreven, embed-versus-reference-benadering fundamenteel verschilt van SQL-normalisatie, is het begrijpen van MongoDB-schemaontwerp — de embed/reference-keuze, wanneer je elk gebruikt en ontwerp voor toegangspatronen — essentieel, waardevol kennis voor het bouwen van effectieve MongoDB-toepassingen, een van de meest belangrijke en karakteristieke MongoDB-onderwerpen dat degenen die goede documentschema's ontwerpen, onderscheidt van degenen die naïef relationele ontwerpen overzetten.