Ciao, e benvenuto nella prima puntata della cinquantacinquesima stagione di questo podcast. Nelle ultime due stagioni abbiamo raccontato due grandi basi di dati, Postgres e MySQL, e abbiamo detto che, pur avendo anime diverse, condividono la stessa idea di fondo su come i dati vanno organizzati: in tabelle, con righe e colonne, legate tra loro. Oggi apriamo una base di dati che quella forma la rifiuta, e ne propone un'altra. Oggi apriamo MongoDB, che chiameremo spesso solo Mongo.
Partiamo dalla ribellione, perché è tutto il senso. Per decenni, dire base di dati voleva dire tabelle. Era così ovvio che quasi nessuno si chiedeva se ci fosse un altro modo. Poi, negli anni della grande esplosione del web, una generazione di sviluppatori cominciò a farsi una domanda scomoda: perché devo spezzare una cosa sola in dieci tabelle diverse, e poi faticare ogni volta per rimetterla insieme? I miei dati, nel codice, sono oggetti ricchi e annidati. Perché la base di dati mi obbliga a smontarli e rimontarli di continuo? Da questa domanda nacque un movimento, e Mongo ne divenne il volto più famoso.
Voglio darti l'idea centrale, perché è semplice e potente. L'idea di Mongo è questa: invece di spezzare i dati in tante tabelle, teniamo insieme una cosa in un unico documento, con la forma con cui esiste nel tuo codice. Un ordine, con dentro i suoi articoli, l'indirizzo di consegna, i dettagli: tutto in un solo posto, annidato, come una scheda completa. Il documento è ricco, flessibile, e assomiglia moltissimo agli oggetti con cui il programmatore già lavora. Mongo, in un certo senso, dice: ti do i dati nella forma in cui li pensi, non nella forma in cui la matematica preferisce archiviarli.
Voglio darti un pezzo di storia, perché spiega il carattere. Non è un caso che Mongo sia nato e cresciuto insieme al mondo di un certo linguaggio, quello del web, dove tutto è fatto di oggetti con campi e valori. Per chi programmava in quel mondo, il documento di Mongo sembrava naturale, familiare, quasi la continuazione del codice dentro la base di dati. Niente traduzione, niente smontaggio: la stessa forma da una parte e dall'altra. Fu una delle ragioni del suo successo travolgente: parlava la lingua degli sviluppatori, non quella dei teorici dei dati. E in un'epoca in cui nascevano applicazioni a ritmo febbrile, e vinceva chi arrivava per primo, sembrare familiare e togliere un passaggio di mezzo non era un dettaglio: era un vantaggio enorme, che fece innamorare intere generazioni di programmatori.
Voglio darti i due pilastri, perché sono la mappa. Su cosa poggia il carattere di Mongo? Su due pilastri. Il primo è il modello a documenti, con la sua flessibilità: tenere insieme ciò che si usa insieme, e poter cambiare forma senza cerimonie. Il secondo è la scalabilità orizzontale: Mongo è nato per spargersi su tante macchine economiche, invece di dipendere da una sola macchina gigante. Fatto per il pensiero dello sviluppatore, e fatto per la scala. Sono questi due pilastri a guidare tutta la stagione.
Voglio prometterti onestà, perché qui serve più che mai. Mongo è una tecnologia che ha diviso. Ha ricevuto entusiasmo enorme e scherno feroce in egual misura. È stato osannato come il futuro e deriso come un giocattolo che perde i dati. La verità, come quasi sempre, sta nel mezzo, ed è più interessante di entrambe le caricature. In questa stagione non faremo né i tifosi né i denigratori. Guarderemo cosa Mongo fa davvero bene, dove è la scelta giusta, e dove invece un database relazionale resta la casa migliore. Un'udienza giusta, che è la cosa che i toni accesi non gli hanno quasi mai dato.
Voglio inquadrare la stagione, perché completa un percorso. Con questa stagione chiudiamo idealmente una piccola trilogia. Le basi di dati in generale, tanto tempo fa. Poi due esponenti del mondo relazionale, le tabelle. E ora un rappresentante del mondo diverso, i documenti. Alla fine avrai in mano non una risposta, ma qualcosa di più prezioso: la capacità di riconoscere che esistono forme diverse per i dati, e di scegliere quella giusta per il tuo problema, invece di piegare ogni problema all'unica forma che conosci. Perché il vero potere non è sapere uno strumento, ma capire che gli strumenti sono tanti.
Per oggi ci fermiamo qui. Abbiamo aperto la stagione su Mongo, la base di dati che rifiuta le tabelle. Dopo due stagioni relazionali, incontriamo un modello diverso, nato dalla domanda: perché spezzare una cosa sola in tante tabelle, se nel codice è già un oggetto ricco e annidato? L'idea di Mongo è tenere insieme una cosa in un unico documento, con la forma con cui esiste nel codice: parla la lingua degli sviluppatori. Poggia su due pilastri, il modello a documenti con la sua flessibilità, e la scalabilità orizzontale. Con una promessa: nessun tifo, nessuna gogna, solo un'udienza giusta. E un percorso che si chiude: capire che per i dati esistono forme diverse, e saperle scegliere. Nella prossima puntata: il documento, tenere insieme ciò che si usa insieme. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.