Hvad er forskellen mellem embedding og referencing?

Question

Accepted Answer

**Embedding** lagrer relaterede data *inden i* et dokument (indlejret); **referencing** lagrer det i *separate* dokumenter linket efter id. Dette er den centrale modelleringsbeslutning i MongoDB, med forskellige kompromiser for læseperformance, datastørrelse og opdateringskompleksitet.

## Embedding — indlejret i dokumentet

```js
{
  _id: ObjectId("..."),
  title: "My Post",
  author: { name: "Ann", email: "ann@x.com" },   // EMBEDDED author
  comments: [                                      // EMBEDDED comments
    { user: "Bob", text: "Great!" },
    { user: "Carol", text: "Thanks" }
  ]
}
// ✓ ONE query gets the post + author + comments (fast, atomic)
// ✗ if author info changes, must update it in every post embedding it (duplication)
// ✗ document grows with comments → could hit the 16MB limit if unbounded
```

## Referencing — separate dokumenter linket efter id

```js
// posts collection
{ _id: ObjectId("p1"), title: "My Post", authorId: ObjectId("u1") }
// users collection
{ _id: ObjectId("u1"), name: "Ann", email: "ann@x.com" }
// comments collection
{ _id: ObjectId("c1"), postId: ObjectId("p1"), user: "Bob", text: "Great!" }

// ✓ author/comments stored ONCE, updated in one place; no document-size issues
// ✓ each entity managed independently
// ✗ need multiple queries or $lookup to combine (slower reads for related data)
```

## Kompromisserne side om side

```text
                  Embedding                    Referencing
Reads             ✓ fast (one query)           ✗ multiple queries / $lookup
Data duplication  ✗ duplicated (update many)   ✓ stored once
Document size     ✗ grows (16MB limit risk)    ✓ no size concern
Updates           ✗ update in every copy       ✓ update in one place
Atomicity         ✓ atomic (single document)   ✗ across documents
Best for          contains, accessed-together  shared, large, independent, many
```

## En hybrid tilgang (almindelig)

```js
// embed a SUBSET for fast reads, reference for the full data
{ title: "Post", author: { _id: ObjectId("u1"), name: "Ann" } }  // enough for display
// → reference (author._id) for full details when needed; embed name for the common read
```

## Hvorfor det betyder noget

Forståelse af embedding vs referencing er den **kerneevne inden for MongoDB datamodeering**, så det er væsentlig viden til at designe effektive MongoDB-applikationer.

Denne beslutning — at lagre relaterede data inden i et dokument (embedding) versus i separate linkede dokumenter (referencing) — bestemmer direkte en applikations læseperformance, datakonsistens, dokumentstørrelse og opdateringskompleksitet, hvilket gør det til den mest betydningsfulde MongoDB-designbeslutning.

Forståelse af **kompromisserne** er afgørende: **embedding** giver hurtige enkelt-forespørgselslæsninger af relaterede data og atomare opdateringer (passer til "indeholder"-relationer, sammen-tilgået data, begrænset underdata) men forårsager duplikering (opdateringskompleksitet hvis dataene er delt) og dokumentvækst (risiko for 16MB-grænsen hvis ubegrænset); **referencing** lagrer data én gang (lette opdateringer, ingen duplikering, ingen størrelsesproblem, uafhængig styring) men kræver flere forespørgsler eller `$lookup` til kombinering (langsommere relateret-data-læsninger).

At vide hvilken der passer til hvilken scenario — embed for begrænset, ejet, sammen-tilgået data; reference for stor, delt, uafhængig, eller mange relationer — er den væsentlige modelleringsvurdering.

Forståelse af den almindelige **hybrid tilgang** (indlejring af en delmængde for hurtige læsninger mens referencing for fuld data — få det bedste fra begge) afspejler sofistikeret design.

Da denne beslutning dybdegående påvirker MongoDB-applikationskvalitet (forkerte valg forårsager langsomme forespørgsler, oppustede dokumenter eller vanskelige opdateringer), og da det er den grundlæggende, karakteristiske MongoDB-modelleringsevne (uden direkte SQL-ækvivalent — SQL normaliserer som standard), er forståelse af embedding vs referencing — kompromisserne, hvornår man bruger hver, og hybrid tilgange — væsentlig, høj-værdi viden der ligger i hjertet af effektiv MongoDB datamodeering og et af de vigtigste og hyppigst diskuterede MongoDB-emner, centralt til at designe skemaer der præsterer godt til en applikations adgangsmønstre.