Ciao, e benvenuto nella quarta puntata della cinquantacinquesima stagione. Oggi affrontiamo la domanda più difficile e più importante di tutto il modello a documenti, quella che separa chi usa Mongo bene da chi si mette nei guai. È il nodo che avevo lasciato in sospeso. Oggi capiamo il prezzo della comodità: duplicare o collegare?
Ripartiamo dal punto dolente, perché è chiaro. Abbiamo detto: tieni insieme ciò che usi insieme. Bello, finché le cose sono davvero separate. Ma la realtà è piena di informazioni condivise. Pensa all'indirizzo di un cliente che ha fatto cento ordini. Il principio del documento direbbe: metti l'indirizzo dentro ogni ordine, così quando leggi l'ordine ce l'hai subito. Ma allora quell'indirizzo è copiato in cento posti. E il giorno in cui il cliente trasloca, devi trovare e aggiornare tutte e cento le copie. Ne dimentichi una, ed ecco un dato sbagliato che si nasconde nel mucchio.
Voglio darti le due strade, perché è la scelta chiave. Davanti a un'informazione condivisa, in Mongo hai due opzioni. La prima è incorporare: copiare l'informazione dentro ogni documento che la usa. Vantaggio: leggere è velocissimo, tutto è già lì. Svantaggio: se quell'informazione cambia, devi aggiornarne tante copie. La seconda strada è collegare: non copiare l'informazione, ma tenerla in un posto solo e mettere, nei documenti, solo un riferimento a quel posto, esattamente come un legame tra tabelle nel mondo relazionale. Vantaggio: l'informazione è in un unico posto, aggiornarla è facile. Svantaggio: per leggerla devi fare un passaggio in più, andarla a prendere là.
Voglio darti l'immagine che rende chiara questa idea, perché è quotidiana. È la differenza tra due modi di tenere il numero di telefono di un amico. Il primo: lo scrivi nella tua rubrica. Comodo, ce l'hai subito. Ma se lui cambia numero, la tua copia resta vecchia finché non la aggiorni a mano. Il secondo: invece del numero, tieni solo un rimando all'elenco ufficiale, e ogni volta vai a guardare lì. Un po' più lento, un passaggio in più, ma il numero è sempre quello giusto, aggiornato alla fonte. Incorporare è la rubrica personale; collegare è il rimando all'elenco. Nessuno dei due è giusto sempre: dipende da quanto spesso quel numero cambia, e da quanto in fretta ti serve averlo sotto mano. La stessa scelta che facciamo, senza pensarci, mille volte nella vita di tutti i giorni.
Voglio darti la regola per scegliere, perché è pratica. Come decidi, allora, caso per caso? Con due domande. Prima: questa informazione cambia spesso, o quasi mai? Se cambia di rado, incorporare fa poco male, perché aggiornerai poco. Se cambia spesso, meglio collegare, per non rincorrere mille copie. Seconda: leggo questa informazione quasi sempre insieme al resto, o solo a volte? Se serve sempre, incorporare fa risparmiare passaggi. Se serve di rado, collegare tiene i documenti snelli. Il mestiere di modellare in Mongo è, in gran parte, rispondere bene a queste due domande, relazione per relazione.
Voglio dirti la verità scomoda, perché è il cuore della puntata. Ed eccola: Mongo non ha abolito i compromessi del mondo relazionale. Li ha solo spostati. Nel mondo delle tabelle, la regola generale è tenere ogni informazione in un posto solo, e ricucire al bisogno: paghi qualcosa in lettura, guadagni in sicurezza degli aggiornamenti. Mongo ti spinge verso l'opposto, duplicare per leggere in fretta, e ti chiede di gestire tu il costo degli aggiornamenti. La differenza vera non è che uno abbia risolto il problema e l'altro no. È che il mondo relazionale mette la regola nel database, e Mongo mette la decisione nelle tue mani. Più libertà, più responsabilità.
Voglio essere equilibrato, perché è giusto. E allora, è un male o un bene? Dipende, ed è una risposta onesta. Se il tuo dato è fatto soprattutto di cose separate, che si leggono insieme e cambiano poco, incorporare è una meraviglia, e Mongo brilla. Se il tuo dato è un intreccio fitto di informazioni condivise che cambiano di continuo e si guardano da mille angolazioni, allora rincorrere le copie diventa un peso, e forse la casa giusta era il mondo relazionale. Non è che Mongo sia peggiore: è che è ottimizzato per una certa forma dei dati. Riconoscere se la tua ha quella forma è metà della decisione. E questa, in fondo, è la maturità di chi sceglie uno strumento: non chiedersi se è buono in assoluto, domanda senza senso, ma se è buono per la forma precisa del problema che ha davanti, in questo momento.
Per oggi ci fermiamo qui. Abbiamo affrontato il nodo del modello a documenti. Tieni insieme ciò che usi insieme è splendido, finché non incontri informazioni condivise, come l'indirizzo copiato in cento ordini. Allora hai due strade: incorporare, copiare dentro, lettura veloce ma aggiornamenti moltiplicati; oppure collegare, tenere in un posto solo con un rimando, aggiornamento facile ma un passaggio in più. Come scrivere il numero nella rubrica o rimandare all'elenco ufficiale. Si sceglie con due domande: cambia spesso? Serve sempre insieme? La verità scomoda: Mongo non ha abolito i compromessi relazionali, li ha spostati dalle regole del database alle tue mani. La lezione: più libertà, più responsabilità, e riconoscere la forma dei tuoi dati. Nella prossima puntata: fare domande ai documenti. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.