Kako dizajnirate sheme u MongoDB?

Question

Accepted Answer

Dizajniranje sheme u MongoDB-u središte je jedne ključne odluke: **ugniježđivanje** (pohranjena povezana data unutar dokumenta) naspram **referenciranja** (pohranjena povezana data u odvojenim dokumentima/zbirkama sa referencama). Za razliku od SQL-a koji normalizira prema zadanom, dizajniranje u MongoDB-u optimizira se prema tome kako se podaci *pristupaju*.

## Ugniježđivanje — pohranite povezane podatke zajedno

```js
// embed related data within the document
{
  _id: ObjectId("..."),
  name: "Ann",
  address: { city: "NY", zip: "10001" },        // embedded sub-document
  orders: [                                      // embedded array of orders
    { product: "Phone", amount: 999 },
    { product: "Case", amount: 20 }
  ]
}
// → ONE query gets the user AND their address AND orders (no joins)
```

**Ugniježđivanje** čuva povezane podatke u jednom dokumentu — pročitajte sve u jednoj upiti (brzo, bez spajanja). Dobro za podatke do kojih se pristupa zajedno i odnose "sadrži".

## Referenciranje — povežite odvojene dokumente

```js
// store a reference (id) to a document in another collection
{ _id: ObjectId("u1"), name: "Ann" }                          // users collection
{ _id: ObjectId("o1"), userId: ObjectId("u1"), product: "Phone" } // orders collection
// → query orders by userId; use $lookup to join when needed
```

**Referenciranje** čuva podatke odvojeno i povezuje ih prema id-u (kao strani ključ) — upitajte odvojeno ili spojite sa `$lookup`.

## Kada ugniježđivati naspram referenciranja

```text
EMBED when:
  ✓ data is accessed TOGETHER (read the parent → you want the children)
  ✓ a "contains"/ownership relationship (address, order line items)
  ✓ the embedded data is bounded (not unboundedly growing)
  ✓ one-to-few relationships

REFERENCE when:
  ✓ data is large or grows UNBOUNDEDLY (avoid huge documents — 16MB doc limit!)
  ✓ data is accessed/updated INDEPENDENTLY
  ✓ many-to-many or one-to-many with many
  ✓ the same data is shared/referenced by many documents (avoid duplication)
```

## Dizajnirajte za obrasce pristupa (ključni princip)

```text
MongoDB schema design is driven by HOW YOU QUERY the data, not pure normalization:
  → Structure data so common queries are efficient (often a single document read).
  → "Data that is accessed together should be stored together."
  → This may mean DENORMALIZING (some duplication) for read efficiency — acceptable
    in MongoDB, traded against update complexity.
```

## Zašto je bitno

Dizajniranje sheme je kritično važno u MongoDB-u — razlikuje se od i argumentirano je konsekventnije nego u SQL-u, jer fleksibilan model dokumenta MongoDB-a vam daje izbore koji značajno utječu na performanse i održavost, pa je razumijevanje toga ključno za izradu učinkovitih MongoDB aplikacija.

Centalna odluka — **ugniježđivanje naspram referenciranja** — je definirajući MongoDB dizajn: **ugniježđivanje** (pohranjena povezana data unutar dokumenta) omogućuje brzo čitanje povezanih podataka jednom upiti (bez spajanja) i odgovara podacima do kojih se pristupa zajedno i odnosima "sadrži", dok **referenciranje** (povezivanje odvojenih dokumenata prema id-u) odgovara velikim/neograničenim podacima, neovisno pristupačnim podacima i zajedničkim/Many odnosima.

Razumijevanje **kada koristiti svaki pristup** (ugniježđivanje za ograničene, zajedno pristupačne, posjedovane podatke; referenciranje za velike/rastuće, neovisne, zajedničke ili Many odnose — i biti svjestan MongoDB ograničenja veličine dokumenta od 16MB) je ključna vještina.

Najvažnije, razumijevanje vodiećeg principa — **dizajnirajte za obrasce pristupa** (strukturirajte podatke oko *kako ih upitujete*, tako da su česti upiti učinkoviti, često čitanje jednog dokumenta, umjesto normalizacije prema zadanom kao SQL) — je ono što razlikuje dobro dizajniranje MongoDB sheme.

Ovo može značiti prihvaćanje neke **denormalizacije** (dupliciranja) za učinkovitost čitanja, kompromis prema kompleksnosti ažuriranja koji je prihvatljiv i često ispravan u MongoDB-u.

Budući da dizajniranje sheme duboko utječe na performanse MongoDB aplikacija i održavost (loš izbor ugniježđivanja/referenciranja uzrokuje spora upita, ogromne dokumente ili kompleksnost ažuriranja), i budući da je pristup vođen obrascima pristupa, pristup ugniježđivanja-naspram-referenciranja fundamentalno drugačiji od SQL normalizacije, razumijevanje MongoDB dizajniranja sheme — odluka o ugniježđivanju/referenciranju, kada koristiti svaki, i dizajniranje za obrasce pristupa — je bitno, vysokovrijednosno znanje za izradu učinkovitih MongoDB aplikacija, jedna od najvažnijih i najzaraznijih MongoDB tema koja odvaja one koji dizajniraju dobre sheme dokumenata od onih koji naivno prenose relacijske dizajne.