MongoDB: modellare i dati senza errori

Lo schema conta, anche senza schema

MongoDB e un database documentale: flessibile, senza schema rigido. Ma questa liberta inganna: modellare male i dati porta a query lente e applicazioni difficili da mantenere. La regola e progettare in base ai pattern di accesso.

Embedding o referencing?

La scelta fondamentale e tra includere i dati correlati nel documento (embedding) o tenerli separati e collegarli (referencing).

// Embedding: dati letti sempre insieme
{
  _id: 1,
  nome: "Linea A",
  sensori: [
    { tipo: "temperatura", unita: "C" },
    { tipo: "vibrazione", unita: "mm/s" }
  ]
}

// Referencing: dati grandi o condivisi
{ _id: 100, lineaId: 1, valore: 72.5, ts: "2025-07-17T10:00:00Z" }

Le linee guida

• Embedding quando i dati si leggono insieme e crescono in modo limitato.
• Referencing quando i dati sono grandi, condivisi tra documenti o crescono senza limite.

L'antipattern da evitare

Documenti che crescono all'infinito (per esempio un array di letture che si espande per sempre) degradano le performance. In questi casi conviene separare i dati in una collection dedicata.

Conclusione

In MongoDB la modellazione segue le query, non l'astrazione teorica. In MUSTNODE progettiamo gli schemi partendo da come i dati verranno effettivamente letti e scritti.