Kuinka suunnittelet kaavioita MongoDB:ssä?

Question

Accepted Answer

MongoDB-kaavion suunnittelu keskittyy keskeiseen päätökseen: **upottaminen** (vastaavan datan tallentaminen dokumentin sisälle) vs **viittaaminen** (vastaavan datan tallentaminen erillisiin dokumentteihin/kokoelmiin viitteillä). Toisin kuin SQL:n normalisointiin perustuva lähestymistapa, MongoDB-suunnittelu optimoidaan datan *käyttöä* varten.

## Upottaminen — tallenna vastaava data yhteen

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

**Upottaminen** pitää vastaavan datan samassa dokumentissa — lue se kaikki yhdessä kyselyssä (nopea, ei liitoksia). Sopii datalle, jota käsitellään yhdessä ja "sisältää" -suhteille.

## Viittaaminen — linkitä erilliset dokumentit

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

**Viittaaminen** tallentaa datan erillään ja linkittää id:llä (kuten ulkoinen avain) — kysy erillään tai liity `$lookup`-operaatiolla.

## Milloin upottaa vs viitata

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

## Suunnittele käyttömalleille (keskeinen periaate)

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

## Miksi se on tärkeää

Kaavisunnitelu on kriittisen tärkeää MongoDB:ssä — se eroaa ja on ehkä jopa vaikutuksaltaan merkittävämpi kuin SQL:ssä, koska MongoDB:n joustava dokumenttimalli tarjoaa valintoja, jotka vaikuttavat merkittävästi suorituskykyyn ja ylläpidettävyyteen, joten sen ymmärtäminen on olennaista tehokkaan MongoDB-sovelluksen rakentamiselle.

Keskeinen päätös — **upottaminen vs viittaaminen** — on määrittelevä MongoDB-suunnittelun valinta: **upottaminen** (vastaavan datan tallentaminen dokumentin sisälle) mahdollistaa nopeat yhden kyselyn luvut vastaavasta datasta (ei liitoksia) ja sopii yhdessä käsiteltävään dataan ja "sisältää" -suhteille, kun taas **viittaaminen** (erillisten dokumenttien linkittäminen id:llä) sopii suurille/rajoittamattomille datamäärille, itsenäisesti käsiteltävälle datalle ja jaetuille/monen-suhteille.

Ymmärtäminen **milloin käyttää kumpaa** (upota rajoitetulle, yhdessä käsiteltävälle, omistetulla datalle; viitata suurelle/kasvavalle, itsenäiselle, jaetulle tai monen-suhteelle — ja muista MongoDB:n 16 Mt:n dokumentin koon raja) on keskeinen taito.

Erittäin tärkeää on **ohjaus periaatteen** ymmärtäminen — **suunnittele käyttömalleille** (jäsennä data sen mukaan, *miten kysyt sitä*, jotta yleiset kyselyt ovat tehokkaita, usein yksittäisen dokumentin luku, ilman SQL:n oletusarvoista normalisointia) — on se, mikä erottaa hyvän MongoDB-kaaviosunnittelun.

Tämä saattaa tarkoittaa jonkin verran **denormalisointia** (kaksoiskappaleiden) hyväksymistä lukutehokkuudelle, kompromissia päivitysten monimutkaisuutta vastaan, joka on hyväksyttävä ja usein oikea MongoDB:ssä.

Koska kaaviosunnittelulla on syvä vaikutus MongoDB-sovelluksen suorituskykyyn ja ylläpidettävyyteen (huono upota/viittaa -valinta aiheuttaa hitaita kyselyitä, valtavia dokumentteja tai päivitysten monimutkaisuutta), ja koska käyttömalleihin perustuva, upota-vs-viittaa-lähestymistapa on perustavanlaatuisesti erilainen kuin SQL-normalisointi, MongoDB-kaaviosunnittelun ymmärtäminen — upota/viittaa-päätös, milloin käyttää kumpaa ja käyttömalleille suunnittelu — on olennaista, korkearvoista tietoa tehokkaan MongoDB-sovelluksen rakentamiselle, yksi tärkeimmistä ja erottautuvimmista MongoDB-aiheista, joka erottaa ne, jotka suunnittelevat hyviä dokumenttikaaviota niistä, jotka naiivisti siirtävät relaationaalisia malleja.