Kaip modeliuoti ryšius MongoDB?

Question

Accepted Answer

MongoDB modeliuoja ryšius (vienas-prie-vieno, vienas-prie-daugelio, daug-prie-daugelio) per **įterpimą** arba **nuorodų naudojimą** — pasirinkimas priklauso nuo ryšio kardinalumo, kaip duomenys pasiekiami ir ar jie bendrinami. Skirtingai nei SQL vienodas užsienio raktų metodas, MongoDB siūlo lankstumą kiekvienam ryšiui.

## Vienas-prie-vieno

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

## Vienas-prie-daugelio (dažniausia — ir pati sudėtingiausia)

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

Pagrindinė subtilybė: **vienas-prie-nedaugelio** (įterpti), **vienas-prie-daugelio** (nuoroda iš daugelio pusės), **vienas-prie-begalybės** (visada nuoroda — niekada neįterpti neapribotų duomenų, dėl 16MB dokumento limito ir našumo).

## Daug-prie-daugelio

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

Daug-prie-daugelio naudoja nuorodų id masyvus (vienoje arba abiejose pusėse), arba atskirą sąryšio kolekciją turtingų ryšio duomenų.

## Nuorodų sprendimas ($lookup)

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

## Kodėl tai svarbu

Ryšių modeliavimas yra pagrindinis duomenų bazės projektavimo elementas, o MongoDB lanksti, pasiekimo šablonom pagrįsta prieiga skiriasi nuo SQL vienodo užsienio raktų metodo, todėl suprasti, kaip modeliuoti ryšius MongoDB, yra būtina veiksmingoms schemoms projektuoti.

Pagrindinė įžvalga yra ta, kad MongoDB modeliuoja ryšius per **įterpimą arba nuorodų naudojimą** pagal ryšio charakteristikas — ir suprasti **kaip kardinalumas veikia pasirinkimą** yra įrodytas įgūdis: **vienas-prie-vieno** (paprastai įterpti — pasiekiami kartu), **vienas-prie-daugelio** su svarbiais niuansais (**vienas-prie-nedaugelio** → įterpti apribotiems kartu pasieikamiems duomenims; **vienas-prie-daugelio** → nuoroda iš daugelio pusės; **vienas-prie-begalybės** → visada nuoroda, niekada neįterpti neapribotų duomenų dėl 16MB dokumento limito ir našumo), ir **daug-prie-daugelio** (nuorodų id masyvai, arba sąryšio kolekciją).

Šis kardinalumu pagrįstas sprendimų priėmimas (ypač atpažįstant, kada duomenys per dideli/neapriboti įterpimui) yra būtinas bendriems klaidoms išvengti, pavyzdžiui, neapribotų masyvų įterpimui (dokumentų padidinimas, ribų pasiekimas) arba per daug nuorodų duomenims, kurie turėtų būti įterpti.

Supratimas, kaip **spręsti nuorodas** su `$lookup` kai sąryšiai reikalingi, užbaigia šią nuotrauką.

Kadangi ryšiai tarp entitetų yra imanentūs daugumoje duomenų modelių, ir kadangi MongoDB lanksti per-ryšio prieiga (įterpti prieš nuorodą pagal kardinalumą ir pasiekimo šablonus) yra iš esmės kitokia ir sudėtingesnė nei SQL vienodas užsienio raktai, suprasti, kaip modeliuoti ryšius MongoDB — kardinalumu pagrįstą įterpimo/nuorodos sprendimus (ypač vienas-prie-nedaugelio/daugelio/begalybės skirtumą) ir spręsti nuorodas — yra būtinas, dažnai naudojamas žinojimas veiksmingam MongoDB schemos projektavimui, besiremiančiam įterpimo/nuorodos pagrindais, kad būtų sprendžiami ryšiai, kuriuos turi kiekviena tikroji aplikacija, ir svarbi sritis, išskiriant solidų MongoDB modeliavimą iš naivaus reliacinių portų.