Jak modelujesz relacje w MongoDB?

Question

Accepted Answer

MongoDB modeluje relacje (jeden-do-jednego, jeden-do-wielu, wiele-do-wielu) poprzez **embedding** lub **referencing** — wybór zależy od kardynalności relacji, sposobu dostępu do danych i tego, czy dane są współdzielone. W przeciwieństwie do jednolitego podejścia SQL z kluczami obcymi, MongoDB oferuje elastyczność dla każdej relacji.

## Jeden-do-jednego

```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-do-wielu (najbardziej powszechne — i najbardziej złożone)

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

Kluczowe niuanse: **jeden-do-kilku** (embed), **jeden-do-wielu** (reference z strony wielu), **jeden-do-miliardów** (zawsze reference — nigdy nie embedduj nieograniczonych danych ze względu na limit 16MB dokumentu i wydajność).

## Wiele-do-wielu

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

Wiele-do-wielu używa tablic referencjonowanych id (po jednej lub obu stronach), lub osobnej kolekcji przypominającej junction do bogatych danych relacyjnych.

## Rozwiązywanie referencji ($lookup)

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

## Dlaczego to ważne

Modelowanie relacji jest fundamentalne dla projektowania baz danych, a elastyczne podejście MongoDB oparte na wzorcach dostępu jest inne niż jednolite klucze obce SQL, dlatego zrozumienie sposobu modelowania relacji w MongoDB jest niezbędne do projektowania efektywnych schematów.

Kluczowym wglądem jest to, że MongoDB modeluje relacje poprzez **embedding lub referencing** na podstawie charakterystyk relacji — i zrozumienie **jak kardynalność wpływa na wybór** jest kluczową umiejętnością: **jeden-do-jednego** (zwykle embed — dostęp łącznie), **jeden-do-wielu** z istotnymi niuansami (**jeden-do-kilku** → embed dla ograniczonych danych dostępnych razem; **jeden-do-wielu** → reference z strony wielu; **jeden-do-miliardów** → zawsze reference, nigdy embedduj nieograniczone dane ze względu na limit 16MB dokumentu i wydajność), i **wiele-do-wielu** (tablice referencjonowanych id, lub kolekcja przypominająca junction).

To oparte na kardynalności podejmowanie decyzji (szczególnie rozpoznanie, kiedy dane są zbyt duże/nieograniczone do embeddowania) jest niezbędne, aby uniknąć typowych błędów, takich jak embeddowanie nieograniczonych tablic (powiększanie dokumentów, osiąganie limitów) lub nadmierne referencing danych, które powinny być embedded.

Zrozumienie sposobu **rozwiązywania referencji** za pomocą `$lookup` gdy potrzebne są joiny uzupełnia obraz.

Ponieważ relacje między encjami są nieodłączne w większości modeli danych, a elastyczne podejście MongoDB dla każdej relacji (embed vs reference na podstawie kardynalności i wzorców dostępu) jest fundamentalnie inne i bardziej złożone niż jednolite klucze obce SQL, zrozumienie sposobu modelowania relacji w MongoDB — decyzje embed/reference oparte na kardynalności (szczególnie rozróżnienie jeden-do-kilku/wielu/miliardów) i rozwiązywanie referencji — jest niezbędną, często stosowaną wiedzą dla efektywnego projektowania schematów MongoDB, budującą na fundamentach embed/reference do obsługi relacji, które ma każda rzeczywista aplikacja, i kluczowym obszarem rozróżniającym solidne modelowanie MongoDB od naiwnych portów relacyjnych.