Jak modelujete vztahy v MongoDB?

Question

Accepted Answer

MongoDB modeluje vztahy (jeden-na-jednoho, jeden-na-mnoho, mnoho-na-mnoho) prostřednictvím **vkládání** nebo **odkazování** — volba závisí na kardinalitě vztahu, na způsobu přístupu k datům a na tom, zda jsou data sdílena. Na rozdíl od jednotného přístupu se zahraničními klíči v SQL nabízí MongoDB flexibilitu pro každý vztah.

## Jeden-na-jednoho

```js
// usually EMBED (the related data belongs to the document)
{ _id: ObjectId("..."), name: "Ann", profile: { bio: "...", avatar: "..." } }
// → one query gets both; they're accessed together
```

## Jeden-na-mnoho (nejčastější — a nejvíce nuancovaný)

```js
// ONE-TO-FEW → embed (bounded, accessed together)
{ _id: ObjectId("..."), name: "Ann", addresses: [ {...}, {...} ] }  // a few addresses

// ONE-TO-MANY → reference (the "many" side references the "one")
// authors collection: { _id: "a1", name: "Ann" }
// books collection:   { _id: "b1", authorId: "a1", title: "..." }  // each book references its author

// ONE-TO-SQUILLIONS (huge/unbounded) → ALWAYS reference (never embed unbounded data)
// e.g. a user with millions of log entries → separate collection, reference by userId
```

Klíčová nuance: **jeden-na-málo** (vložit), **jeden-na-mnoho** (odkaz ze strany mnoha), **jeden-na-obrovství** (vždy odkaz — nikdy nevkládat neomezená data kvůli limitu 16MB dokumentu a výkonu).

## Mnoho-na-mnoho

```js
// reference with an array of ids (on one or both sides)
{ _id: "s1", name: "Student", courseIds: ["c1", "c2"] }     // student → courses
{ _id: "c1", name: "Course", studentIds: ["s1", "s2"] }     // course → students (optional)
// → query and $lookup to resolve; or a separate "enrollments" collection (junction-like)
```

Mnoho-na-mnoho používá pole odkazovaných id (na jedné nebo obou stranách), nebo oddělenou sbírku podobnou spojovací tabulce pro bohatá data vztahu.

## Řešení odkazů ($lookup)

```js
// join referenced data when needed
db.books.aggregate([
  { $lookup: { from: "authors", localField: "authorId", foreignField: "_id", as: "author" } }
]);
```

## Proč na tom záleží

Modelování vztahů je fundamentální pro návrh databází, a flexibilní přístup MongoDB řízený vzorem přístupu se liší od jednotného způsobu zahraničních klíčů SQL, takže pochopení toho, jak modelovat vztahy v MongoDB, je nezbytné pro návrh efektivních schémat.

Klíčová myšlenka je, že MongoDB modeluje vztahy prostřednictvím **vkládání nebo odkazování** na základě charakteristik vztahu — a pochopení **toho, jak kardinalita ovlivňuje volbu**, je zásadní dovednost: **jeden-na-jednoho** (obvykle vložit — přístup dohromady), **jeden-na-mnoho** se svými důležitými nuancemi (**jeden-na-málo** → vložit pro omezená data přístupná dohromady; **jeden-na-mnoho** → odkaz ze strany mnoha; **jeden-na-obrovství** → vždy odkaz, nikdy nevkládat neomezená data kvůli limitu 16MB dokumentu a výkonu), a **mnoho-na-mnoho** (pole odkazovaných id, nebo sbírka podobná spojovací tabulce).

Toto rozhodování řízené kardinalitou (zejména rozpoznání, kdy jsou data příliš velká/neomezená na vkládání) je nezbytné pro vyhnutí se běžným chybám jako vkládání neomezených polí (zatěžování dokumentů, dosažení limitů) nebo nadměrné odkazování na data, která by měla být vložena.

Pochopení toho, jak **řešit odkazy** pomocí `$lookup` když jsou potřeba spojení, doplňuje celkový obrázek.

Protože vztahy mezi entitami jsou přítomny ve většině datových modelů, a protože flexibilní přístup MongoDB pro každý vztah (vkládání vs. odkazování na základě kardinalitu a vzorů přístupu) je fundamentálně odlišný a nuancovanější než jednotný přístup zahraničních klíčů SQL, pochopení toho, jak modelovat vztahy v MongoDB — rozhodnutí o vkládání/odkazování řízená kardinalitou (zejména rozdíl jeden-na-málo/mnoho/obrovství) a řešení odkazů — je nezbytné, často používané znalosti pro efektivní návrh schématu MongoDB, která navazují na fundamenty vkládání/odkazování, aby se zvládly vztahy, které má každá skutečná aplikace, a klíčová oblast odlišující zvukové modelování MongoDB od naivních portů z relačních databází.