Hoe model je relaties in MongoDB?

Question

Accepted Answer

MongoDB modelleert relaties (een-op-een, een-op-veel, veel-op-veel) via **embedding** of **referencing** — de keuze hangt af van de cardinaliteit van de relatie, hoe de gegevens worden benaderd, en of deze worden gedeeld. In tegenstelling tot SQL's uniforme foreign-key-benadering biedt MongoDB flexibiliteit per relatie.

## Een-op-een

```js
// usually EMBED (the related data belongs to the document)
{ _id: ObjectId("..."), name: "Ann", profile: { bio: "...", avatar: "..." } }
// → one query gets both; they're accessed together
```

## Een-op-veel (het meest voorkomend — en het meest genuanceerd)

```js
// ONE-TO-FEW → embed (bounded, accessed together)
{ _id: ObjectId("..."), name: "Ann", addresses: [ {...}, {...} ] }  // a few addresses

// ONE-TO-MANY → reference (the "many" side references the "one")
// authors collection: { _id: "a1", name: "Ann" }
// books collection:   { _id: "b1", authorId: "a1", title: "..." }  // each book references its author

// ONE-TO-SQUILLIONS (huge/unbounded) → ALWAYS reference (never embed unbounded data)
// e.g. a user with millions of log entries → separate collection, reference by userId
```

De cruciale nuance: **een-op-weinig** (embed), **een-op-veel** (reference van de veel-zijde), **een-op-miljarden** (altijd reference — nooit onbegrensde gegevens embedden, vanwege de 16MB-documentlimiet en performance).

## Veel-op-veel

```js
// reference with an array of ids (on one or both sides)
{ _id: "s1", name: "Student", courseIds: ["c1", "c2"] }     // student → courses
{ _id: "c1", name: "Course", studentIds: ["s1", "s2"] }     // course → students (optional)
// → query and $lookup to resolve; or a separate "enrollments" collection (junction-like)
```

Veel-op-veel gebruikt arrays van referenced ids (aan één of beide zijden), of een aparte junction-achtige collectie voor rijke relatiegegevens.

## References oplossen ($lookup)

```js
// join referenced data when needed
db.books.aggregate([
  { $lookup: { from: "authors", localField: "authorId", foreignField: "_id", as: "author" } }
]);
```

## Waarom het belangrijk is

Het modelleren van relaties is fundamenteel voor databaseontwerp, en MongoDB's flexibele, op toegangspatroon gebaseerde benadering verschilt van SQL's uniforme foreign keys, dus het begrijpen van hoe je relaties in MongoDB modelleert is essentieel voor het ontwerpen van effectieve schema's.

Het cruciale inzicht is dat MongoDB relaties modelleert via **embedding of referencing** gebaseerd op de kenmerken van de relatie — en het begrijpen van **hoe cardinaliteit de keuze beïnvloedt** is de essentiële vaardigheid: **een-op-een** (meestal embed — samen benaderd), **een-op-veel** met belangrijke nuances (**een-op-weinig** → embed voor begrensde samen-benaderde gegevens; **een-op-veel** → reference van de veel-zijde; **een-op-miljarden** → altijd reference, nooit onbegrensde gegevens embedden vanwege de 16MB-documentlimiet en performance), en **veel-op-veel** (arrays van referenced ids, of een junction-achtige collectie).

Deze cardinaliteit-gestuurde besluitvorming (vooral het herkennen wanneer gegevens te groot/onbegrensd zijn om in te bedden) is essentieel om veelvoorkomende fouten te vermijden, zoals het embedden van onbegrensde arrays (opblazen van documenten, limietoverschrijding) of overmatig referencing van gegevens die zouden moeten worden ingebed.

Het begrijpen hoe je **references oplost** met `$lookup` wanneer joins nodig zijn completeert het plaatje.

Omdat relaties tussen entiteiten inherent zijn in de meeste gegevensmodellen, en omdat MongoDB's flexibele per-relatie-benadering (embed versus reference gebaseerd op cardinaliteit en toegangspatronen) fundamenteel anders en meer genuanceerd is dan SQL's uniforme foreign keys, is het begrijpen hoe je relaties in MongoDB modelleert — de cardinaliteit-gebaseerde embed/reference-beslissingen (vooral het een-op-weinig/veel/miljarden-onderscheid) en het oplossen van references — essentieel, regelmatig toegepast kennis voor effectief MongoDB-schemaontwerp, voortbouwend op de embed/reference-fundamentals om de relaties aan te pakken die elke echte toepassing heeft, en een belangrijk onderscheidend gebied tussen degelijk MongoDB-modelleren en naïeve relationale porteringen.