Ciao, e benvenuto nella seconda puntata della cinquantacinquesima stagione. Oggi entriamo nel cuore di Mongo, nell'idea da cui tutto il resto discende, quella che devi capire davvero se vuoi capire tutto il resto. Oggi parliamo del documento, e del principio di tenere insieme ciò che si usa insieme.
Partiamo dal contrasto, perché rende tutto chiaro. Ricordi come funziona il mondo relazionale? Prendi un ordine di un negozio. Nel mondo delle tabelle, quell'ordine è sparpagliato: l'ordine in una tabella, gli articoli acquistati in un'altra, l'indirizzo di consegna in un'altra ancora, i dati del cliente da un'altra parte. Sono pezzi collegati da riferimenti, e ogni volta che vuoi vedere l'ordine completo, devi andare a raccoglierli in giro e ricucirli insieme. È ordinato, è pulito, ma è sparpagliato.
Voglio darti l'alternativa di Mongo, perché è radicale. Mongo dice: e se tenessimo tutto l'ordine in un posto solo? In Mongo, quell'ordine è un unico documento: dentro ci sono i suoi articoli, annidati come una lista; dentro c'è l'indirizzo di consegna, annidato come un blocchetto; dentro ci sono i dettagli che servono. Non è sparpagliato in quattro tabelle: è una scheda unica e completa, che contiene tutto ciò che riguarda quell'ordine. Vuoi vedere l'ordine? Prendi un documento, uno solo, ed è tutto lì, già montato.
Voglio darti il principio profondo, perché è la chiave di volta della stagione. Il principio che guida Mongo è uno solo, e vale la pena inciderlo: tieni insieme ciò che usi insieme. Se, quando mostri una pagina, ti servono sempre insieme l'ordine, i suoi articoli e il suo indirizzo, allora tienili insieme, nello stesso documento. Così, quando ti servono, sono già lì, in un colpo solo, senza dover correre a raccoglierli. È un'inversione di prospettiva: il mondo relazionale organizza i dati per come sono fatti in teoria; Mongo li organizza per come li usi in pratica.
Voglio darti l'immagine che rende chiara questa idea, perché è concreta. Pensa a due modi di archiviare i documenti di una pratica, per esempio la pratica di un cliente. Il primo modo: metti i contratti in un armadio, le fatture in un altro, la corrispondenza in un terzo, e tieni degli elenchi che dicono quali fogli, in quali armadi, appartengono a quel cliente. Ordinato, ma per vedere tutta la pratica devi girare per la stanza aprendo cassetti. Il secondo modo, quello di Mongo: una sola cartellina, con dentro tutto ciò che riguarda quel cliente, contratti, fatture, lettere, tutto insieme. La apri, ed è tutto lì.
Voglio dirti perché questo è così potente, perché non è solo comodità. Il vantaggio non è estetico, è di velocità e di semplicità. Per costruire la pagina di un ordine, in Mongo fai una sola richiesta e ottieni un solo documento già completo. Nel mondo relazionale, spesso, devi fare più richieste o ricuciture per rimettere insieme i pezzi. Quando la cosa che leggi coincide con la cosa che hai salvato, non c'è nessun lavoro di rimontaggio: è già nella forma che ti serve. E siccome quasi ogni applicazione legge molto più di quanto scrive, ottimizzare la lettura in questo modo è una vittoria che si sente.
Voglio già seminare il dubbio, perché sarà il tema delle prossime puntate. Ma attenzione, perché ogni scelta ha un rovescio, e questa non fa eccezione. Tenere tutto insieme è meraviglioso finché le cose sono davvero separate: ogni ordine ha i suoi articoli, che non appartengono a nessun altro. Ma cosa succede quando una stessa informazione serve a tante schede diverse? L'indirizzo di un cliente che compra cento volte: lo copio dentro tutti e cento gli ordini? E se cambia? Questo è il grande nodo del modello a documenti, e sarà il cuore delle prossime due puntate: la flessibilità della forma, e il prezzo della duplicazione.
Voglio trarre la lezione generale, perché va oltre Mongo. La lezione è che il modo in cui organizzi i dati dovrebbe seguire il modo in cui li usi, non un ideale astratto di ordine. Il mondo relazionale parte dalla struttura perfetta e poi ricuce al bisogno. Mongo parte dall'uso e tiene insieme ciò che va insieme. Nessuno dei due è sbagliato: sono due filosofie di partenza opposte. E capire questa differenza, tieni insieme ciò che usi insieme, è già capire l'ottanta per cento di cosa sia Mongo e perché esista.
Per oggi ci fermiamo qui. Siamo entrati nel cuore di Mongo, il documento. Dove il mondo relazionale sparpaglia un ordine in tante tabelle da ricucire, Mongo lo tiene in un unico documento: articoli, indirizzo, dettagli, tutto annidato in una scheda completa. Il principio è tieni insieme ciò che usi insieme: organizzare i dati per come li usi, non per come sono fatti in teoria. Come una sola cartellina con tutta la pratica dentro, invece di fogli sparsi in tre armadi. È potente perché leggere diventa un colpo solo, senza rimontaggio. Ma con un rovescio già in vista: e quando una stessa informazione serve a tante schede? La lezione: i dati vanno organizzati per come si usano. Nella prossima puntata: cambiare forma senza chiedere permesso. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.