Dove vive davvero lo schema del database
Informazioni sui contenuti e sulla loro verifica
In questo articolo
Tutto ciò che questo servizio fa sta nel controllo di versione. Il codice, quanto meno. Il database su cui gira sono 32 tabelle, e 15 di esse non hanno una definizione da nessuna parte nel repository — nessun CREATE TABLE, nessun file di schema, niente. Una copia ripristina tutte e 32 con la loro forma intatta; quello che il repository non tiene è una seconda copia indipendente di quella forma.
Queste cifre vengono dal confronto fra il database in funzione e 736 file, 5.671.710 caratteri di repository. Non sono una stima.
Come sparisce metà di uno schema
Non è sciatteria, ed è proprio questo a renderlo degno di essere scritto. Ogni singolo passo era ragionevole.
Le tabelle create prima del codice attuale non sono mai state messe per iscritto, perché all'epoca c'erano e basta. Le tabelle aggiunte da allora sono arrivate con script di migrazione, e quelli sono nel repository — da lì vengono le 17 definizioni. Le colonne aggiunte più tardi sono arrivate con un ALTER TABLE di una riga digitato a un prompt, perché digitarlo era più veloce che scrivere uno script per una modifica che dura un secondo.
Gli indici sono il caso peggiore. Un indice si aggiunge quando qualcosa è lento, nel momento in cui è lento, e risolve subito. Non resta nessun artefatto, niente da rileggere, niente che fallisca se te ne dimentichi. Undici dei trentadue indici secondari di qui esistono esattamente per questo e non sono registrati da nessuna parte.
La tabella in cui stanno i contatori stessi, 166.438 righe, è fra le quindici senza definizione nel repository.
Che cosa si rompe davvero
Poco, fino a un momento preciso: quando il database viene ripristinato da un dump.
Un dump porta con sé la struttura, quindi un ripristino diretto va bene. Il pericolo è ogni percorso che ricostruisce una tabella invece di ripristinarla — un trasloco su un'altra macchina, l'import di tabelle scelte, la ricreazione da uno script. I dati tornano, gli indici silenziosamente no. Niente fallisce. Le query restituiscono le risposte giuste. Ci mettono solo di più, e la causa è invisibile, perché l'unica traccia di che cosa fosse l'indice sta sulla macchina che non ce l'ha più.
È questo il guasto da nominare: un indice mancante non produce un errore, produce una risposta corretta più lenta. Non c'è un test per questo, perché i test passano.
Che cosa facciamo nel frattempo
Lo schema oggi non è nel repository, e questa è la descrizione esatta dello stato. Quello che c’è è più stretto di una soluzione completa e copre il caso che costa davvero qualcosa:
Un dump prima di qualunque cosa distruttiva, tenuto fuori dalla radice web. Un ripristino davvero eseguito almeno una volta, invece che dato per fatto. E un elenco breve, controllato dopo ogni ripristino, degli indici che si sa esistere solo nel database in funzione — perché alla macchina si può chiedere quali indici ha, e la risposta si può confrontare con l'ultima volta.
La versione generale vale per più dei database. Se una parte del sistema esiste solo nel sistema in funzione, non ne esiste una seconda copia. La domanda che vale la pena porsi su qualunque pezzo di infrastruttura non è se sia salvato, ma che cosa non si potrebbe ricostruire dal repository se la macchina sparisse. Qui la risposta è quindici tabelle e undici indici, stabilirlo è costato un pomeriggio, ed è un elenco invece di un’incognita.
Aggiornamento: settembre 2026
Cinque giorni dopo questo articolo la cartella di lavoro è finita nel repository: 26 file e 4058 righe, fra cui undici script di migrazione scritti fra il 28 agosto e il 1 settembre che fino ad allora esistevano solo sulla macchina in funzione. Era la metà facile — codice scritto ma mai registrato.
Il 1 settembre 2026 la misura è stata rifatta allo stesso modo: il database in funzione contro tutto ciò che git conosce.
| Tabelle | 46 | 30 con un CREATE TABLE nel repository, 16 senza |
| Indici secondari | 43 | 32 creati da codice nel repository, 11 solo nel database in funzione |
| Script di migrazione | 109 | sotto controllo di versione |
Il numero che conta non si è mosso. Il 27 agosto undici indici secondari non esistevano da nessuna parte se non nel database in funzione. Il 1 settembre sono ancora undici. Nel frattempo sono arrivati altri undici indici, e ognuno è arrivato con uno script di migrazione: è cambiata l’abitudine, non il debito.
Gli undici stanno su cinque tabelle — i contatori, le lingue, i referenti, la lista di esclusione e il registro degli eventi. Tutte e cinque sono più vecchie del codice attuale, ed è proprio per questo che per loro non è mai stato scritto nulla. Scrivere un file adesso vorrebbe dire ricostruire da un server in funzione ciò che anni fa è stato digitato a un prompt.
La posizione di agosto resta quindi valida. Lo schema continua a non essere nel repository, e un ripristino che ricostruisce una tabella invece di riportarla indietro perderebbe ancora undici indici senza una parola. È cambiato il meno: tutto ciò che si è aggiunto da allora ha lasciato un file.