Hva er forskjellen mellom embedding og referencing?

Question

Accepted Answer

**Embedding** lagrer relaterte data *inne* i et dokument (nestet); **referencing** lagrer det i *separate* dokumenter koblet sammen via id. Dette er den sentrale modelleringsbeslutningen i MongoDB, med ulike avveiinger for leseytelse, datastørrelse og oppdateringskompleksitet.

## Embedding — nestet innen 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 koblet sammen via 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)
```

## Avveiingene side ved 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 hybridtilnærming (vanlig)

```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 betyr noe

Å forstå embedding kontra referencing er **kjernekompetansen innen MongoDB-datamodellering**, så det er vesentlig kunnskap for å utforme effektive MongoDB-applikasjoner.

Denne beslutningen — å lagre relaterte data inne i et dokument (embedding) eller i separate koblede dokumenter (referencing) — avgjør direkte en applikasjons leseytelse, datakonsistens, dokumentstørrelse og oppdateringskompleksitet, noe som gjør det til den mest konsekvensielle MongoDB-designbeslutningen.

Å forstå **avveiingene** er nøkkelen: **embedding** gir raske enkeltspørring-lesinger av relaterte data og atomiske oppdateringer (passer for "inneholder"-relasjoner, sammen-aksessert data, begrenset deldata) men forårsaker duplisering (oppdateringskompleksitet hvis dataene er delt) og dokumentvekst (risiko for 16MB-grensen hvis ubegrenset); **referencing** lagrer data én gang (enkle oppdateringer, ingen duplisering, ingen størrelsesproblem, uavhengig håndtering) men krever flere spørringer eller `$lookup` for å kombinere (langsommere lesinger av relaterte data).

Å vite hvilken som passer hvilken situasjon — embed for begrenset, eiet, sammen-aksessert data; referencing for stor, delt, uavhengig eller mange relasjoner — er den vesentlige modelleringsvurderingen.

Å forstå den vanlige **hybridtilnærmingen** (embedding av en delmengde for raske lesinger samtidig som man refererer til fullstendige data — å få det beste fra begge) gjenspeiler sofistikert design.

Ettersom denne beslutningen har dyp innvirkning på MongoDB-applikasjonskvalitet (feil valg forårsaker langsomme spørringer, oppblåste dokumenter eller vanskelige oppdateringer), og siden det er den grunnleggende, særegne MongoDB-modelleringsferdigheten (uten direkte SQL-ekvivalent — SQL normaliserer som standard), er forståelse av embedding kontra referencing — avveiingene, når man skal bruke hver av dem, og hybridtilnærminger — vesentlig, høyverdig kunnskap som er hjerteslaget i effektiv MongoDB-datamodellering og et av de viktigste og hyppigst diskuterte MongoDB-temaene, sentralt for å utforme skjemaer som presterer godt for en applikasjons tilgangsmønstre.