Hvordan designer man skemaer i MongoDB?

Question

Accepted Answer

MongoDB-skemadesign handler om en vigtig beslutning: **embedding** (lagring af relaterede data inden for et dokument) vs **referencing** (lagring af relaterede data i separate dokumenter/collections med referencer). I modsætning til SQLs normaliser-som-standard-tilgang optimerer MongoDB-design for, hvordan dataene *tilgås*.

## Embedding — lagring af relaterede data sammen

```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** holder relaterede data i ét dokument — læs det hele i en enkelt forespørgsel (hurtigt, ingen joins). Godt for data, der tilgås sammen, og "indeholder"-relationer.

## Referencing — linke separate dokumenter

```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** lagrer data separat og linker via id (som en foreign key) — forespørg separat eller join med `$lookup`.

## Hvornår skal man embed vs reference

```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)
```

## Design for tilgangsmønstre (nøgleprincippet)

```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.
```

## Hvorfor det betyder noget

Skemadesign er kritisk vigtig i MongoDB — det er anderledes end og potentielt mere afgørende end i SQL, fordi MongoDBs fleksible dokumentmodel giver dig valg, der væsentligt påvirker ydeevne og vedligeholdelsesmulighed, så forståelse heraf er essentiel for at bygge effektive MongoDB-applikationer.

Den centrale beslutning — **embedding vs referencing** — er det definerende MongoDB-designvalg: **embedding** (lagring af relaterede data inden for et dokument) muliggør hurtig læsning af relaterede data i en enkelt forespørgsel (ingen joins) og passer til data, der tilgås sammen, og "indeholder"-relationer, mens **referencing** (linkning af separate dokumenter via id) passer til store/ubegrænsede data, uafhængigt tilgåede data og delte/mange-relationer.

At forstå **hvornår man bruger hver enkelt** (embed for afgrænsede, sammen-tilgåede, ejede data; reference for store/voksende, uafhængige, delte eller mange-relationer — og være opmærksom på MongoDBs 16MB dokumentstørrelsesbegrænsning) er nøglefærdigheden.

Vigtigst af alt er det at forstå det vejledende princip — **design for tilgangsmønstre** (strukturer data omkring *hvordan du forespørger det*, så almindelige forespørgsler er effektive, ofte en enkelt dokumentlæsning, i stedet for at normalisere som standard som SQL) — som adskiller god MongoDB-skemadesign.

Dette kan betyde at acceptere nogle **denormalisering** (duplikering) for læseeffektivitet, en afvejning mod opdateringsompleksitet, som er acceptabel og ofte korrekt i MongoDB.

Da skemadesign dybt påvirker MongoDB-applikationens ydeevne og vedligeholdelsesmulighed (et dårligt embed/reference-valg forårsager langsomme forespørgsler, massive dokumenter eller opdateringskompleksitet), og da den adgangsmønster-drevet, embed-vs-reference-tilgang er fundamentalt anderledes end SQL-normalisering, er forståelse af MongoDB-skemadesign — embed/reference-beslutningen, hvornår man bruger hver enkelt, og design for tilgangsmønstre — essentiel, værdifuld viden for at bygge effektive MongoDB-applikationer, et af de vigtigste og mest karakteristiske MongoDB-emner, som adskiller dem, der designer gode dokumentskemaer, fra dem, der naivt porter relationelle designs.