Qual è la differenza tra embedding e referencing?

Question

Accepted Answer

**Embedding** memorizza i dati correlati *all'interno* di un documento (annidati); **referencing** li memorizza in *documenti separati* collegati per id. Questa è la decisione di modellazione fondamentale in MongoDB, con diversi compromessi per le prestazioni di lettura, la dimensione dei dati e la complessità degli aggiornamenti.

## Embedding — annidati all'interno del documento

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

## Referencing — documenti separati collegati per id

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

## I compromessi a confronto

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

## Un approccio ibrido (comune)

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

## Perché è importante

Comprendere embedding vs referencing è la **competenza fondamentale della modellazione dei dati MongoDB**, quindi è una conoscenza essenziale per progettare applicazioni MongoDB efficaci.

Questa decisione — memorizzare dati correlati all'interno di un documento (embedding) rispetto a documenti separati collegati (referencing) — determina direttamente le prestazioni di lettura dell'applicazione, la coerenza dei dati, la dimensione del documento e la complessità degli aggiornamenti, rendendola la scelta di progettazione MongoDB più consequenziale.

Comprendere i **compromessi** è fondamentale: l'**embedding** offre letture veloci da una singola query di dati correlati e aggiornamenti atomici (adatto per relazioni "contiene", dati accessibili insieme, dati secondari delimitati) ma causa duplicazione (complessità di aggiornamento se i dati sono condivisi) e crescita del documento (rischio del limite di 16MB se non delimitato); il **referencing** memorizza i dati una sola volta (aggiornamenti facili, nessuna duplicazione, nessun problema di dimensione, gestione indipendente) ma richiede più query o `$lookup` per combinarli (letture di dati correlati più lente).

Sapere quale si adatta a quale scenario — embedding per dati delimitati, posseduti, accessibili insieme; referencing per dati grandi, condivisi, indipendenti, o molte relazioni — è il giudizio di modellazione essenziale.

Comprendere l'**approccio ibrido** comune (embedding di un sottoinsieme per letture veloci mentre si fa referencing per i dati completi — ottenendo il meglio di entrambi) riflette un design sofisticato.

Poiché questa decisione influisce profondamente sulla qualità dell'applicazione MongoDB (scelte sbagliate causano query lente, documenti gonfi, o aggiornamenti difficili), e poiché è la competenza di modellazione fondamentale e distintiva di MongoDB (senza equivalente diretto in SQL — SQL normalizza per impostazione predefinita), comprendere embedding vs referencing — i compromessi, quando usare ciascuno e gli approcci ibridi — è conoscenza essenziale e di alto valore che è al cuore della modellazione efficace dei dati MongoDB e uno degli argomenti MongoDB più importanti e frequentemente discussi, centrale per progettare schemi che hanno buone prestazioni per i modelli di accesso di un'applicazione.