Koks yra skirtumas tarp duomenų įterpimo ir nuorodos sudarymo?

Question

Accepted Answer

**Įterpimas** saugo susijusius duomenis *viduje* dokumento (įdėtai); **nuoroda** juos saugo *atskiruose* dokumentuose, susieti pagal id. Tai yra pagrindinė modeliavimo sprendimo vieta MongoDB, su skirtingais kompromisais dėl skaitymo našumo, duomenų dydžio ir atnaujinimo sudėtingumo.

## Įterpimas — įdėta dokumento viduje

```js
{
  _id: ObjectId("..."),
  title: "My Post",
  author: { name: "Ann", email: "ann@x.com" },   // EMBEDDED author
  comments: [                                      // EMBEDDED comments
    { user: "Bob", text: "Great!" },
    { user: "Carol", text: "Thanks" }
  ]
}
// ✓ ONE query gets the post + author + comments (fast, atomic)
// ✗ if author info changes, must update it in every post embedding it (duplication)
// ✗ document grows with comments → could hit the 16MB limit if unbounded
```

## Nuoroda — atskiri dokumentai susieti pagal id

```js
// posts collection
{ _id: ObjectId("p1"), title: "My Post", authorId: ObjectId("u1") }
// users collection
{ _id: ObjectId("u1"), name: "Ann", email: "ann@x.com" }
// comments collection
{ _id: ObjectId("c1"), postId: ObjectId("p1"), user: "Bob", text: "Great!" }

// ✓ author/comments stored ONCE, updated in one place; no document-size issues
// ✓ each entity managed independently
// ✗ need multiple queries or $lookup to combine (slower reads for related data)
```

## Kompromisai šalia šalia

```text
                  Embedding                    Referencing
Reads             ✓ fast (one query)           ✗ multiple queries / $lookup
Data duplication  ✗ duplicated (update many)   ✓ stored once
Document size     ✗ grows (16MB limit risk)    ✓ no size concern
Updates           ✗ update in every copy       ✓ update in one place
Atomicity         ✓ atomic (single document)   ✗ across documents
Best for          contains, accessed-together  shared, large, independent, many
```

## Hibridinis požiūris (dažnas)

```js
// embed a SUBSET for fast reads, reference for the full data
{ title: "Post", author: { _id: ObjectId("u1"), name: "Ann" } }  // enough for display
// → reference (author._id) for full details when needed; embed name for the common read
```

## Kodėl tai svarbu

Supratimas apie įterpimą ir nuorodą yra **pagrindinė MongoDB duomenų modeliavimo įgūdis**, todėl tai yra esminės žinios, skirtos efektyvaus MongoDB programų projektavimui.

Šis sprendimas — saugoti susijusius duomenis dokumento viduje (įterpimas) arba atskiruose susietus dokumentuose (nuoroda) — tiesiogiai nulemia programos skaitymo našumą, duomenų nuoseklumą, dokumento dydį ir atnaujinimo sudėtingumą, todėl tai yra labiausiai reikšmingas MongoDB dizaino pasirinkimas.

Supratimas apie **kompromisus** yra svarbus: **įterpimas** suteikia greitą vieno užklausos skaitymo iš susijusių duomenų ir atomines atnaujinimus (tinkamas "yra dalis" santykiams, kartu pasiekiamiems duomenims, apribotos sub-duomenims), bet sukelia pasikartojimą (atnaujinimo sudėtingumą, jei duomenys yra bendrinami) ir dokumento augimą (rizikuojant 16MB ribu, jei neribotas); **nuoroda** saugo duomenis kartą (lengvi atnaujinimai, nėra pasikartojimo, nėra dydžio problemų, nepriklausomas valdymas), bet reikalinga keletas užklausų arba `$lookup` norint sujungti (lėtas susijusių duomenų skaitymą).

Žinoti, kuri tinka kuriam scenarijui — įterpti apribotus, savininkams priklausančius, kartu pasiekiamus duomenis; nuoroda į didelius, bendrus, nepriklausimus arba daug santykių — yra esminė modeliavimo nuojauta.

Supratimas apie bendrą **hibridinį požiūrį** (greitam skaitymui įterpimas iš dalies, o visiškai duomenims — nuoroda — geriausios iš abiejų pusės) atspindi patiklų dizainą.

Kadangi šis sprendimas profundai veikia MongoDB programos kokybę (klaidingi pasirinkimai sukelia lėtas užklausas, išpūstus dokumentus arba skausmingus atnaujinimus), ir kadangi tai yra pagrindinė, išskirtina MongoDB modeliavimo įgūdis (be tiesioginio SQL ekvivalento — SQL pagal numatytuosius nustatymus normalizuoja), supratimas apie įterpimą ir nuorodą — kompromisus, kada kiekvieną naudoti, ir hibridinės strategijos — yra esminė, didelės vertės žinios, kurios yra veiksmingojo MongoDB duomenų modeliavimo širdyje ir viena iš svarbiausių bei dažniausiai diskutuojamų MongoDB temų, pagrindinės schemos projektavimui, kuris gerai atitinka programos prieigos modelius.