Ciao, e benvenuto nella settima puntata della cinquantasettesima stagione. Oggi parliamo di una parte dell'ecosistema dei mappatori che non riguarda la lettura o la scrittura dei dati, ma la forma stessa del database, e come farla evolvere nel tempo senza impazzire. Oggi parliamo dello schema che vive nel codice: le migrazioni.
Partiamo dal problema, perché è quotidiano e doloroso. La forma di un database, cioè quali tabelle esistono e quali colonne hanno, non è scolpita nella pietra. Cambia in continuazione: aggiungi una colonna per un nuovo campo, crei una tabella per una nuova funzione, rinomini qualcosa. Ora immagina di lavorare in squadra. Tu fai una modifica alla forma del database sul tuo computer. Come fa il tuo collega ad avere la stessa identica modifica sul suo? E come si applica la stessa modifica, in modo sicuro, al database vero, quello in produzione, dove vivono i dati reali degli utenti? Se ognuno cambia la forma a mano, il caos è garantito: database diversi su macchine diverse, e nessuno che sa più quale sia quella giusta.
Voglio darti la soluzione, perché è semplice ed elegante. Le migrazioni risolvono questo caos con un'idea potente: descrivi ogni cambiamento della forma del database come un piccolo copione, un file, che vive dentro il codice del progetto. Ogni copione dice, per esempio: aggiungi la colonna telefono alla tabella utenti. Questi copioni sono numerati, ordinati nel tempo, e conservati insieme al codice. Per portare qualunque database alla forma più recente, basta eseguirli in ordine, uno dopo l'altro. Il tuo collega scarica il codice, esegue i copioni che gli mancano, e il suo database diventa identico al tuo. La forma del database smette di essere una cosa che vive solo nella testa di qualcuno: diventa codice, versionato insieme a tutto il resto.
Voglio dirti cosa ci guadagni, perché è tanto. Il primo guadagno è la riproducibilità: chiunque, su qualunque macchina, può ricostruire esattamente la stessa forma del database partendo da zero, semplicemente eseguendo i copioni in ordine. Il secondo è la storia: hai un registro ordinato e datato di come la forma del database si è evoluta, chi ha aggiunto cosa e quando. Il terzo è il lavoro di squadra senza scontri: le modifiche di ognuno diventano copioni che si mettono in fila con quelli degli altri, senza pestarsi i piedi. È lo stesso spirito che abbiamo incontrato parlando di controllo di versione e di automazione: rendere ogni cambiamento tracciabile, ripetibile, condiviso.
Voglio darti l'immagine che rende chiara questa idea, perché la fissa. Pensa al libretto dei lavori di un edificio. Ogni ristrutturazione, ogni muro spostato, ogni stanza aggiunta, viene annotata su una pagina datata, in ordine. Chiunque legga quel libretto, dall'inizio alla fine, capisce esattamente come l'edificio è diventato quello che è oggi. E se dovessi ricostruire l'edificio identico altrove, ti basterebbe seguire il libretto pagina per pagina. Le migrazioni sono il libretto dei lavori del tuo database: la cronaca ordinata di ogni modifica alla sua struttura, che chiunque può leggere e chiunque può rieseguire.
Voglio essere onesto sul lato scomodo, perché c'è anche qui. Ma anche questa comodità ha il suo lato oscuro, e non stupirà, visto il tema della stagione. Eseguire una modifica alla forma di una tabella è banale quando la tabella è piccola. Ma su una tabella enorme, in produzione, con milioni di righe e utenti collegati in quel momento, la stessa innocua modifica può bloccare la tabella per un tempo lungo, rendendo l'applicazione inutilizzabile per minuti. Il copione sembrava semplice, ma sotto stava chiedendo al database un'operazione pesantissima. Anche qui, l'astrazione nasconde il costo, e chi non conosce la macchina sotto rischia di mandare in tilt il sistema con quella che sembrava una modifichina da nulla.
Voglio darti la lezione generale, perché è un principio che ami già. La lezione è che tutto ciò che conta dovrebbe diventare codice: non solo la logica del programma, ma anche la forma dei dati, la configurazione, l'infrastruttura. Quando una cosa è codice, diventa versionabile, condivisibile, ripetibile, revisionabile. Esce dalla nebbia del si fa così, lo sa solo Mario, ed entra nella luce di qualcosa che chiunque può leggere, capire e riprodurre. Le migrazioni portano questo principio alla forma del database. E come sempre, la comodità di uno strumento non ti solleva dal dovere di capire cosa fa, soprattutto quando lo lanci sui dati veri.
Per oggi ci fermiamo qui. Abbiamo visto le migrazioni, lo schema che vive nel codice. La forma di un database cambia sempre, e farlo a mano, in squadra, è il caos. Le migrazioni descrivono ogni cambiamento come un copione numerato e ordinato, conservato col codice: eseguendoli in ordine, qualunque database raggiunge la forma più recente. Ci guadagni riproducibilità, una storia datata, e lavoro di squadra senza scontri. Come il libretto dei lavori di un edificio, che chiunque può leggere e rieseguire. Con un lato onesto: su tabelle enormi in produzione, una modifica banale può bloccare tutto, se non conosci il costo che nasconde. La lezione: tutto ciò che conta dovrebbe diventare codice. Nella prossima puntata: il dialetto e la promessa della portabilità. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.