Ciao, e benvenuto nell'ottava puntata della cinquantacinquesima stagione. Oggi facciamo la cosa più utile e più onesta di tutta la stagione: mettere da parte le tifoserie e chiederci, con serenità, dove Mongo è davvero la scelta giusta, e dove invece non lo è. Oggi capiamo lo strumento giusto per il lavoro giusto.
Partiamo dalla guerra, per superarla. Per anni c'è stata una guerra di religione: da una parte i sostenitori dei documenti che sfottevano le vecchie tabelle, dall'altra i difensori del relazionale che deridevano Mongo come un giocattolo. Entrambi avevano torto, perché ponevano la domanda sbagliata. La domanda non è quale sia migliore in assoluto. Non esiste il database migliore in assoluto, così come non esiste l'attrezzo migliore in assoluto. La domanda giusta è: qual è la forma dei miei dati, e quale strumento è fatto per quella forma?
Voglio dirti dove Mongo brilla, con precisione. Mongo dà il meglio quando i tuoi dati sono naturalmente a forma di documento: cose che vivono come unità intere, che leggi tutte insieme, e che non sono un intreccio fitto di relazioni. Il catalogo di prodotti di un negozio, ogni prodotto una scheda ricca e diversa dalle altre. I contenuti di un sito o di un blog. I profili degli utenti. I dati che arrivano a fiumi da sensori o da eventi. E quando la forma dei dati cambia in fretta, o varia da caso a caso, o quando devi crescere a dismisura su tante macchine. Su questi terreni, Mongo non è un ripiego: è spesso la scelta migliore, davvero.
Voglio dirti dove Mongo fatica, con altrettanta onestà. E ora l'altra faccia, senza sconti. Mongo fatica quando i tuoi dati sono un intreccio fitto di relazioni, dove il valore sta proprio nei legami: tutto è collegato a tutto, e devi interrogare quelle connessioni da mille angolazioni diverse, in modi che non avevi previsto. Pensa a un sistema di contabilità, a un gestionale complesso, a qualsiasi cosa dove le relazioni sono il cuore. Lì il mondo relazionale, con le sue tabelle e i suoi legami, resta la casa migliore. E fatica quando ti servono, come norma quotidiana, garanzie ferree su operazioni che toccano molte entità insieme.
Voglio darti l'immagine che rende chiara questa idea, perché chiude il tema. È come scegliere il veicolo giusto. Un fuoristrada è magnifico sui sentieri di montagna e ridicolo in un parcheggio di città. Una piccola utilitaria è perfetta in città e disperata sulle rocce. Nessuno dei due è il veicolo migliore: dipende da dove devi andare. Mongo è splendido sul suo terreno, i dati a documento, la scala, la flessibilità; e goffo su un altro, gli intrecci relazionali fitti. Il bravo non è chi ama un veicolo, è chi sa leggere la strada e scegliere di conseguenza. E la stessa persona, in giorni diversi e per progetti diversi, sceglierà veicoli diversi senza contraddirsi: perché non è fedele a uno strumento, è fedele al problema che ha davanti.
Voglio essere onesto sugli errori reali, perché sono istruttivi. In questi anni si sono visti due errori speculari, ed entrambi fanno male. Il primo: squadre che hanno scelto Mongo per moda, per hype, e poi ci hanno infilato dati profondamente relazionali, ritrovandosi a rincorrere copie e a reinventare i legami che il mondo delle tabelle offriva gratis. Il secondo, opposto: squadre che hanno snobbato Mongo per pregiudizio, e hanno spremuto un modello a tabelle per gestire documenti flessibili che Mongo avrebbe accolto con naturalezza. Due facce dello stesso sbaglio: scegliere per tribù, non per problema.
Voglio trarre la lezione generale, perché è la più importante del podcast. È il filo che ripetiamo da sempre, e qui raggiunge la sua forma più nitida. Non esiste il migliore in assoluto: esiste il giusto per questo problema. E per saperlo scegliere non devi tifare, devi capire: capire la forma dei tuoi dati, e capire per quale forma ciascuno strumento è nato. È faticoso, richiede di conoscere più di uno strumento, e di resistere alla comodità di usare sempre lo stesso martello. Ma è esattamente questa fatica a separare l'artigiano dall'ideologo. L'artigiano guarda il lavoro, e poi sceglie l'attrezzo. E c'è una piccola ironia a lieto fine in tutto questo: le buone idee di Mongo hanno contagiato anche i rivali, e oggi persino i database a tabelle sanno maneggiare bene i documenti. Alla fine, la battaglia ha reso tutti migliori.
Per oggi ci fermiamo qui. Abbiamo messo da parte le tifoserie. La guerra tra documenti e tabelle poneva la domanda sbagliata: non quale sia migliore in assoluto, ma quale sia fatto per la forma dei tuoi dati. Mongo brilla sui dati a documento, unità intere lette insieme, forme mutevoli, scala enorme: catalogo, contenuti, profili, eventi. Mongo fatica sugli intrecci fitti di relazioni interrogate da mille angoli, dove il relazionale resta la casa migliore. Come scegliere tra fuoristrada e utilitaria: dipende dalla strada. Con due errori speculari da evitare: sceglierlo per moda su dati relazionali, o snobbarlo per pregiudizio su dati a documento. La lezione: non tifare, capire la forma del problema. Nella prossima puntata: open source e i giganti del cloud. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.