Ciao, e benvenuto nell'ottava puntata della cinquantatreesima stagione. Oggi torniamo al primo pilastro, la fiducia, e lo guardiamo da un'angolazione precisa: non come Postgres sopravvive ai guasti, ma come impedisce che i tuoi dati diventino sbagliati in partenza. Oggi capiamo il guardiano della verità: tipi, vincoli e integrità.
Partiamo dall'idea centrale, perché ribalta un'abitudine. Molti pensano che il controllo dei dati sia un lavoro dell'applicazione: è il programma che deve verificare che un'email abbia la forma giusta, che un prezzo non sia negativo, che un ordine appartenga a un cliente che esiste. E in parte è vero. Ma c'è un'idea più profonda: le stesse regole andrebbero messe anche dentro la base di dati. Perché la base di dati è l'ultima linea di difesa, quella che nessuno può aggirare, ed è lì che la verità dei tuoi dati va protetta per davvero.
Voglio darti gli strumenti, perché sono concreti. Postgres offre diversi modi di far rispettare le regole. Il primo sono i tipi: ogni colonna ha una natura, e una colonna fatta per le date rifiuta di contenere la parola banana. Poi ci sono i vincoli: puoi dire questo campo non può essere vuoto, oppure questo valore deve essere unico, non possono esistere due clienti con la stessa email. E infine le chiavi esterne, che fanno rispettare le relazioni: non puoi inserire un ordine che punta a un cliente inesistente, e non puoi cancellare un cliente lasciando in giro i suoi ordini orfani. La base di dati controlla, e se una regola è violata, rifiuta.
Voglio dirti perché metterle nella base di dati, e non solo nell'app, perché è il cuore. La ragione è potente: nel corso degli anni, tante cose diverse toccano gli stessi dati. Non c'è solo la tua applicazione. C'è un'altra applicazione che nasce dopo. C'è lo script che qualcuno lancia una notte per sistemare una cosa. C'è la persona che si collega a mano per una correzione urgente. Ognuno di questi può sbagliare. Se le regole vivono solo dentro una applicazione, tutti gli altri le aggirano, e i dati marci entrano lo stesso. Se invece vivono nella base di dati, valgono per tutti, sempre, qualunque sia la porta da cui si entra.
Voglio darti l'immagine che rende chiara questa idea, perché è netta. Pensa a un buttafuori all'ingresso di un locale, ma un buttafuori piazzato nel punto in cui tutti, obbligatoriamente, devono passare. Non importa se arrivi dall'entrata principale, dalla porta sul retro o dalla finestra: prima di entrare nella stanza dei dati, passi da lui, e lui controlla che tu rispetti le regole. Mettere le regole nell'applicazione è come avere un buttafuori solo alla porta principale: chi conosce il retro entra indisturbato. Mettere le regole nella base di dati è il buttafuori all'unico varco che esiste davvero.
Voglio collegarlo a una tesi recente, perché è la stessa. È lo stesso spirito della sicurezza di cui parlavamo poco fa: non fidarsi di chi arriva da fuori, verificare invece di presumere. Qui la base di dati non si fida di nessuno di quelli che le scrivono, nemmeno delle applicazioni che tu stesso hai costruito, perché sa che nel tempo cambieranno, si moltiplicheranno, sbaglieranno. Non è sfiducia verso di te: è la saggezza di sapere che la verità dei dati deve sopravvivere a tutti i programmi che la toccheranno, e quindi va difesa nel punto che a tutti sopravvive.
Voglio essere onesto sul compromesso, perché esiste. C'è una tensione vera, qui. Mettere le regole nella base di dati la rende più rigida: un cambiamento richiede più cura, e alcuni preferiscono tenere i controlli nell'applicazione per muoversi più in fretta e cambiare idea più facilmente. È una scelta legittima, e dipende da quanto valgono, per te, la flessibilità di oggi contro la certezza di domani. Ma su una cosa vale la pena essere fermi: per le regole più sacre, quelle la cui violazione sarebbe un disastro irreparabile, il posto giusto è la base di dati. La verità dei dati vive più a lungo di qualsiasi applicazione.
Voglio trarre la lezione generale, perché va oltre Postgres. La lezione è che la correttezza dei dati non è un optional da controllare qua e là: è una proprietà da difendere nel punto giusto. E il punto giusto è quello per cui tutti devono passare, quello che sopravvive ai cambi di applicazione, di team, di anni. Postgres ti dà gli strumenti per fare della base di dati quel guardiano: non un magazzino passivo che accetta tutto, ma un custode attivo che rifiuta ciò che violerebbe le regole. È l'altra faccia della fiducia: non solo non perdere i dati, ma non lasciarli mai diventare falsi.
Per oggi ci fermiamo qui. Abbiamo visto il guardiano della verità. L'idea: le regole sui dati non vanno solo nell'applicazione, ma anche nella base di dati, l'ultima linea che nessuno può aggirare. Gli strumenti sono i tipi (una colonna data rifiuta banana), i vincoli (non vuoto, unico) e le chiavi esterne (niente ordini senza cliente). Perché nel tempo tante cose toccano gli stessi dati, e se le regole vivono solo in un'app, tutti gli altri le aggirano. Come un buttafuori piazzato all'unico varco che esiste. È lo stesso spirito della sicurezza: non fidarsi di chi scrive, verificare. Con un compromesso onesto sulla rigidità, ma per le regole sacre il posto è la base di dati. La lezione: difendi la correttezza nel punto che sopravvive a tutti. Nella prossima puntata: non solo tabelle, l'estensibilità. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.