Kako oblikujete sheme v MongoDB?

Question

Accepted Answer

Oblikovanje sheme MongoDB je osredotočeno na ključno odločitev: **vstavljanje** (shranjevanje povezanih podatkov znotraj dokumenta) v primerjavi s **povezovanjem** (shranjevanje povezanih podatkov v ločenih dokumentih/zbirkah z referencami). Za razliko od SQL-a, ki privzeto normalizira, je oblikovanje MongoDB optimizirano za način, kako se podatki *dostopajo*.

## Vstavljanje — shranjevanje povezanih podatkov skupaj

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

**Vstavljanje** drži povezane podatke v enem dokumentu — berite vse v enem poizvedovanju (hitro, brez spajanja). Dobro je za podatke, dostopane skupaj, in za odnose "vsebuje".

## Povezovanje — povezava ločenih dokumentov

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

**Povezovanje** shranjuje podatke ločeno in se povezuje z id-jem (kot tuji ključ) — poizvedujte ločeno ali se spojite z `$lookup`.

## Kdaj vstaviti v primerjavi s povezovanjem

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

## Oblikovanje za vzorce dostopa (ključno načelo)

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

## Zakaj je to pomembno

Oblikovanje sheme je kritično pomembno v MongoDB — razlikuje se od in je morda bolj posledično kot v SQL, ker MongoDB-jev fleksibilen model dokumentov vam daje izbire, ki bistveno vplivajo na zmogljivost in vzdržljivost, zato je razumevanje tega bistveno za gradnjo učinkovitih MongoDB aplikacij.

Osrednja odločitev — **vstavljanje v primerjavi s povezovanjem** — je opredelujoča izbira oblikovanja MongoDB: **vstavljanje** (shranjevanje povezanih podatkov znotraj dokumenta) omogoča hitre bralne dostope enega poizvedovanja do povezanih podatkov (brez spajanja) in je primerno za podatke, dostopane skupaj, in za odnose "vsebuje", medtem ko **povezovanje** (povezava ločenih dokumentov z id-jem) je primerno za velike/neomejene podatke, neodvisno dostopane podatke in skupne/številne odnose.

Razumevanje **kdaj uporabiti vsako** (vstaviti za omejene, skupaj dostopane, lastniške podatke; povezati za velike/rastoče, neodvisne, skupne ali številne odnose — in biti pazljiv na omejitev velikosti dokumenta MongoDB-ja 16MB) je ključna spretnost.

Najbolj pomembno je razumevanje vodilnega načela — **oblikovanje za vzorce dostopa** (strukturiranje podatkov okoli *kako jih poizvedujete*, tako da so pogosti poizvedovalniki učinkoviti, pogosto enkrat branje dokumenta, namesto da privzeto normalizirate kot SQL) — to je ono, kar razlikuje dobro oblikovanje sheme MongoDB.

To lahko pomeni sprejemanje neke **denormalizacije** (podvajanja) za učinkovitost branja, zamenjave proti kompleksnosti posodobitve, ki je sprejemljiva in pogosto pravilna v MongoDB.

Ker oblikovanje sheme globoko vpliva na zmogljivost in vzdržljivost MongoDB aplikacije (slaba izbira vstavljanja/povezovanja povzroči počasne poizvedovalike, ogromne dokumente ali kompleksnost posodobitve), in ker je pristop voden po vzorcih dostopa, vstavljanja v primerjavi s povezovanjem, temeljno drugačen od SQL normalizacije, je razumevanje oblikovanja sheme MongoDB — odločitev vstavljanja/povezovanja, kdaj uporabiti vsako in oblikovanje za vzorce dostopa — bistveno, dragoceno znanje za gradnjo učinkovitih MongoDB aplikacij, eni izmed najpomembnejših in najbolj značilnih tem MongoDB, ki loči tiste, ki oblikujejo dobre sheme dokumentov, od tistih, ki naivno prenesejo relacijske oblike.