Hur designar du scheman i MongoDB?

Question

Accepted Answer

MongoDB-schemadesign centreras kring ett nyckelbeslut: **embedding** (lagring av relaterad data inuti ett dokument) vs **referencing** (lagring av relaterad data i separata dokument/samlingar med referenser). Till skillnad från SQL:s normalize-by-default optimerar MongoDB-design för hur data *åtkomst*.

## Embedding — lagra relaterad data tillsammans

```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** håller relaterad data i ett dokument — läs allt i en enda fråga (snabbt, inga joins). Bra för data som åtkomsts tillsammans och "contains"-relationer.

## Referencing — länka separata dokument

```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** lagrar data separat och länkar via id (som en foreign key) — fråga separat eller slå samman med `$lookup`.

## När du ska använda embedding vs referencing

```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 för åtkomstmönster (nyckelprincipien)

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

## Varför det är viktigt

Schemadesign är kritiskt viktigt i MongoDB — det skiljer sig från och är möjligen mer konsekventiellt än i SQL, eftersom MongoDB:s flexibla dokumentmodell ger dig val som signifikant påverkar prestanda och underhållbarhet, så att förstå det är väsentligt för att bygga effektiva MongoDB-applikationer.

Huvudbeslut — **embedding vs referencing** — är det definierade MongoDB-designvalet: **embedding** (lagring av relaterad data inom ett dokument) möjliggör snabba single-query-läsningar av relaterad data (inga joins) och passar data som åtkomsts tillsammans och "contains"-relationer, medan **referencing** (länkning av separata dokument via id) passar stor/obegränsad data, oberoende åtkomst av data och delad/many-relationer.

Att förstå **när man ska använda varje** (embed för begränsad, tillsammans-åtkomst, ägd data; reference för stor/växande, oberoende, delad eller many-relationer — och vara medveten om MongoDB:s 16MB-dokumentstorleksgräns) är nyckelfärdigheten.

Viktigast av allt, förstå vägledningsprincipen — **design för åtkomstmönster** (strukturera data kring *hur du frågar den*, så vanliga frågor är effektiva, ofta en enskild dokumentläsning, snarare än normalisering by default som SQL) — är vad som skiljer bra MongoDB-schemadesign.

Detta kan innebära att acceptera viss **denormalisering** (duplication) för läseffektivitet, en kompromiss mot uppdateringskomplexitet som är acceptabel och ofta korrekt i MongoDB.

Eftersom schemadesign profunderar påverkar MongoDB-applikationsprestanda och underhållbarhet (ett dåligt embed/reference-val orsakar långsamma frågor, enorma dokument eller uppdateringskomplexitet), och eftersom åtkomstmönster-driven, embed-vs-reference-approach är fundamentalt olika från SQL-normalisering, är det väsentligt, högt värderat kunskap att förstå MongoDB-schemadesign — embed/reference-beslut, när man ska använda varje, och designa för åtkomstmönster — väsentligt för att bygga effektiva MongoDB-applikationer, ett av de viktigaste och mest distinkta MongoDB-ämnena som skiljer de som designar bra dokumentscheman från de som naivt portar relationella design.