Jak navrhujete schémata v MongoDB?

Question

Accepted Answer

Návrh schémat v MongoDB se soustředí na klíčové rozhodnutí: **embedding** (ukládání souvisejících dat v jednom dokumentu) versus **referencing** (ukládání souvisejících dat v samostatných dokumentech/kolekcích s odkazy). Na rozdíl od SQL přístupu normalizace jako výchozího, návrh v MongoDB optimalizuje na základě *způsobu přístupu* k datům.

## Embedding — ukládání souvisejících dat dohromady

```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** uchovává související data v jednom dokumentu — přečtete si všechna v jednom dotazu (rychle, bez joinů). Vhodné pro data, která se čtou dohromady, a pro vztahy "obsahuje".

## Referencing — propojení samostatných 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** ukládá data odděleně a propojuje je pomocí id (jako cizí klíč) — dotazují se samostatně nebo se spojují pomocí `$lookup`.

## Kdy embeddovat versus 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)
```

## Návrh pro přístupové vzory (klíčový princip)

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

## Proč je to důležité

Návrh schémat je kriticky důležitý v MongoDB — liší se od SQL přístupu a je v řadě ohledů důležitější, protože flexibilní dokument model MongoDB vám dává volby, které významně ovlivňují výkon a udržovatelnost, proto je pochopení nezbytné pro vytváření efektivních MongoDB aplikací.

Centrální rozhodnutí — **embedding versus referencing** — je definující volba návrhu v MongoDB: **embedding** (ukládání souvisejících dat v rámci dokumentu) umožňuje rychlé čtení související data jedním dotazem (bez joinů) a hodí se pro data čtená dohromady a vztahy "vlastní", zatímco **referencing** (propojení samostatných dokumentů podle id) se hodí pro velká/neomezená data, nezávisle přistupovaná data a sdílené/many vztahy.

Rozdílení **kdy použít které** (embed pro omezená, dohromady přistupovaná, vlastněná data; reference pro velká/rostoucí, nezávislá, sdílená nebo many vztahy — a mějte na paměti limit 16 MB pro velikost dokumentu v MongoDB) je klíčová dovednost.

Nejdůležitější je pochopení vedoucího principu — **návrh pro přístupové vzory** (strukturujte data kolem *toho, jak je dotazujete*, aby byly běžné dotazy efektivní, často čtení jednoho dokumentu, místo normalizace jako výchozího kroku jako v SQL) — to je to, co rozlišuje dobrý návrh schémat MongoDB.

To může znamenat přijetí určitého **denormalizace** (duplikace) pro efektivnost čtení, kompromis proti složitosti aktualizací, který je akceptovatelný a často správný v MongoDB.

Protože návrh schémat hluboce ovlivňuje výkon a udržovatelnost MongoDB aplikací (špatná volba embedding/referencing způsobuje pomalé dotazy, obrovské dokumenty nebo složitost aktualizací), a protože přístup řízený vzory přístupu a embedding-versus-referencing je zásadně odlišný od SQL normalizace, pochopení návrhu schémat v MongoDB — rozhodnutí embedding/reference, kdy použít které, a návrh pro přístupové vzory — je nezbytné, cenné znalosti pro vytváření efektivních MongoDB aplikací, jedno z nejdůležitějších a nejcharakterističtějších témat MongoDB, které odlišuje ty, kdo navrhují dobré schémata dokumentů, od těch, kdo naivně přenesou relační návrhy.