Koja je razlika između ugniježđivanja i referenciranja?

Question

Accepted Answer

**Ugniježđivanje** pohranjuje povezane podatke *unutar* dokumenta (ugniježđeno); **referenciranje** ih pohranjuje u *odvojenim* dokumentima povezanim po id-u. Ovo je osnovna odluka pri modeliranju u MongoDB-u, sa različitim kompromisima za performanse čitanja, veličinu podataka i složenost ažuriranja.

## Ugniježđivanje — ugniježđeno u dokumentu

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

## Referenciranje — odvojeni dokumenti povezani po id-u

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

## Kompromisi usporedo

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

## Hibridni pristup (čest)

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

## Zašto je to važno

Razumijevanje ugniježđivanja naspram referenciranja je **osnovna vještina MongoDB modeliranja podataka**, zato je to neophodno znanje za dizajniranje učinkovitih MongoDB aplikacija.

Ova odluka — pohrana povezanih podataka unutar dokumenta (ugniježđivanje) naspram u odvojenim povezanim dokumentima (referenciranje) — izravno određuje performanse čitanja aplikacije, konzistentnost podataka, veličinu dokumenta i složenost ažuriranja, čineći je najznačajnijom MongoDB odlukom dizajna.

Razumijevanje **kompromisa** je ključno: **ugniježđivanje** omogućava brzo čitanje povezanih podataka u jednom upitu i atomske ažuriranja (pogodno za "sadrži" odnose, podatke koji se čitaju zajedno, ograničene pod-podatke) ali uzrokuje dupliciranje (složenost ažuriranja ako su podaci dijeljeni) i rast dokumenta (rizik od prekoračenja 16MB granice ako je neograničeno); **referenciranje** pohranjuje podatke samo jednom (lako ažuriranje, nema dupliciranja, nema problema sa veličinom, neovisno upravljanje) ali zahtijeva više upita ili `$lookup` za kombiniranje (sporije čitanje povezanih podataka).

Znanje koja situacija zahtijeva koji pristup — ugniježđivanje za ograničene, vlastite, zajedno pristupane podatke; referenciranje za velike, dijeljene, neovisne ili brojne odnose — je bitno modeliranje.

Razumijevanje čestog **hibridnog pristupa** (ugniježđivanje podskupa za brzo čitanje dok se referencira za potpune podatke — dobivanje boljeg od oboga) pokazuje sofisticirani dizajn.

Budući da ova odluka duboko utječe na kvalitetu MongoDB aplikacije (pogrešne odluke uzrokuju spora pitanja, naduvane dokumente ili bolna ažuriranja), i budući da je to fundamentalna, karakteristična MongoDB vještina modeliranja (bez izravnog SQL ekvivalenta — SQL se normalizira po zadanom), razumijevanje ugniježđivanja naspram referenciranja — kompromisa, kada koristiti svako, i hibridnih pristupa — je neophodno, dragocjeno znanje koje je u srcu učinkovitog MongoDB modeliranja podataka i jedno od najpbitnijih i najčešće diskutiranih MongoDB tema, centralno za dizajniranje shema koje dobro rade za obrasce pristupa aplikacije.