Cum proiectezi scheme în MongoDB?

Question

Accepted Answer

Proiectarea schemelor în MongoDB se concentrează pe o decizie cheie: **embedding** (stocarea datelor conexe în interiorul unui document) vs **referencing** (stocarea datelor conexe în documente/colecții separate cu referințe). Spre deosebire de normalizarea implicită a SQL-ului, proiectarea MongoDB optimizează modul în care datele sunt *accesate*.

## Embedding — stochează datele conexe împreună

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

**Embedding** păstrează datele conexe într-un singur document — citește-le pe toate într-o singură interogare (rapid, fără joinuri). Bun pentru datele accesate împreună și relațiile de tip "contains".

## Referencing — leagă documente separate

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

**Referencing** stochează datele separat și le leagă după id (ca o cheie externă) — interogheaza separat sau leagă cu `$lookup`.

## Când să embedding vs reference

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

## Proiectează pentru modele de acces (principiul cheie)

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

## De ce conteaza

Proiectarea schemelor este extrem de importantă în MongoDB — este diferită de și arguabil mai consecventă decât în SQL, deoarece modelul flexibil de documente al MongoDB-ului îți oferă alegeri care afectează semnificativ performanța și ușurința în mentenanță, deci înțelegerea acesteia este esențială pentru a construi aplicații MongoDB eficace.

Decizia centrală — **embedding vs referencing** — este alegerea de proiectare definitorie a MongoDB: **embedding** (stocarea datelor conexe în interiorul unui document) permite lecturi rapide cu o singură interogare a datelor conexe (fără joinuri) și se potrivește datelor accesate împreună și relațiilor de tip "contains", în timp ce **referencing** (legarea documentelor separate după id) se potrivește datelor mari/nemărginite, datelor accesate independent și relațiilor împărțite/multiple.

Înțelegerea **când să folosești fiecare** (embedding pentru date mărginite, accesate împreună, deținute; referencing pentru date mari/în creștere, independente, împărțite sau multiple — și ținând cont de limita de 16MB a dimensiunii documentului MongoDB) este abilitatea cheie.

Cea mai importantă este înțelegerea principiului conducător — **proiectează pentru modele de acces** (structurează datele în jurul *modului în care le interogezi*, astfel încât interogările comune sunt eficiente, adesea o singură lectură de document, mai degrabă decât normalizarea implicită ca în SQL) — este ceea ce distinge proiectarea bună a schemelor MongoDB.

Aceasta poate însemna acceptarea unor **denormalizări** (duplicate) pentru eficiența citirii, un compromis împotriva complexității actualizării care este acceptabil și adesea corect în MongoDB.

Deoarece proiectarea schemelor afectează profund performanța și ușurința în mentenanță a aplicațiilor MongoDB (o alegere embedding/reference slabă cauzeaza interogări lente, documente uriașe sau complexitate de actualizare), și deoarece abordarea condusă de modelele de acces, embedding-vs-reference, este fundamental diferită de normalizarea SQL, înțelegerea proiectării schemelor MongoDB — decizia embedding/reference, când să folosești fiecare și proiectarea pentru modele de acces — este cunoștințe esențiale și de valoare mare pentru a construi aplicații MongoDB eficace, una dintre cele mai importante și distinctive subiecte MongoDB care separă pe cei care proiectează bine schemele de documente de cei care transportă naiv desenele relaționale.