Tre errori che fanno tutti con i database (e come evitarli)

Quando apro il database di un progetto esistente per la prima volta, spesso mi viene voglia di chiudere tutto e far finta di non aver visto niente. Non è cattiveria: è che certi errori li vedo ripetersi da 20 anni, sempre gli stessi, su progetti diversi. E il bello è che li ho fatti pure io all'inizio, quindi non mi sento migliore di nessuno.

Il punto è che lavorare con i database è come costruire le fondamenta di una casa. Puoi fare tutto il resto perfetto, ma se sbagli lì sotto prima o poi vengono i problemi. E non sono problemi che si sistemano con un aggiornamento WordPress, purtroppo.

Oggi vi racconto i tre errori più comuni che vedo nei database, quelli che mi fanno perdere più tempo quando devo lavorare su un software gestionale su misura o ristrutturare un progetto esistente.

Non usare gli indici (o usarli a caso)

Questo è il classico. Un mio cliente aveva un gestionale per la sua officina meccanica, fatto qualche anno fa da un altro sviluppatore. Funzionava, ma quando la lista interventi superava i duemila record, aprire la scheda cliente diventava un'agonia. Parliamo di 15-20 secondi di attesa.

Apro il database e cosa scopro? Zero indici sulle colonne che venivano interrogate continuamente. Ogni volta che cercava gli interventi di un cliente, il database scansionava tutte le righe una per una. Tremila, cinquemila, diecimila righe. Una follia.

Gli indici sono come l'indice di un libro: se devi trovare un argomento specifico, vai direttamente alla pagina giusta invece di sfogliare tutto. Sembra banale, ma quante volte vedo tabelle con milioni di righe e nessun indice sulle foreign key o sulle colonne usate nelle WHERE?

D'altra parte, c'è anche chi esagera nella direzione opposta. Ho visto database con indici su ogni singola colonna, anche quelle mai usate nelle query. Risultato: le INSERT diventano lente perché ogni volta deve aggiornare dieci indici diversi. L'indice giusto sulla colonna giusta fa la differenza, ma serve sapere cosa si sta indicizzando e perché.

La mia regola pratica: metti indici sulle foreign key, sulle colonne che usi nelle JOIN e nelle WHERE frequenti. Poi misura le performance con EXPLAIN e aggiusta il tiro. Non prima.

Salvare tutto in un'unica tabella gigante

Quest'estate mi arriva una richiesta da un'azienda che vendeva corsi online. Avevano una web app fatta in casa che gestiva iscrizioni, pagamenti, materiali didattici. Tutto dentro una tabella chiamata dati_corsi con 87 colonne.

Ottantasette. Non sto scherzando.

Dentro c'era di tutto: nome corsista, email, indirizzo, telefono, corso scelto, stato pagamento, data iscrizione, link materiali, note interne, preferenze newsletter. Alcune colonne erano sempre vuote, altre duplicate, altre ancora con valori separati da virgole (tipo "corso1,corso3,corso7").

Modificare qualcosa era un incubo. Aggiungere un campo nuovo significava alterare una tabella con centomila righe. Le query erano lunghe come il Codice Civile e nessuno capiva più cosa facevano.

Il problema si chiama "mancanza di normalizzazione". Quando progetti un database, devi dividere i dati in tabelle logiche separate. Una tabella per gli utenti, una per i corsi, una per le iscrizioni che le collega. È la base della base, ma quante volte la vedo ignorata "tanto funziona lo stesso"?

Certo, ci sono casi dove denormalizzare serve per questioni di performance. Ma sono casi specifici, misurati, consapevoli. Non "butto tutto in una tabella perché non ho voglia di pensarci".

Abbiamo ristrutturato tutto in due settimane: cinque tabelle pulite invece di una mostruosa. Il codice è diventato leggibile, le query veloci, le modifiche semplici. E soprattutto, non serviva più una laurea in archeologia per capire dove erano salvate le informazioni.

Ignorare i vincoli e le relazioni

Questo è sottile ma micidiale. Un database senza vincoli (constraints) è come una città senza semafori: prima o poi succede il disastro.

Pochi mesi fa stavo lavorando su un progetto Laravel per un ristoratore di Rovereto che voleva un sistema di prenotazioni. Ereditavo il database di un sistema precedente fatto con PHP puro. In teoria aveva le foreign key definite nello schema, ma nessun vincolo effettivo a livello di database.

Risultato? Prenotazioni collegate a tavoli che non esistevano più. Clienti cancellati ma con ordini ancora attivi. Dati orfani sparsi ovunque che mandavano in crash l'applicazione in modi imprevedibili.

Il codice verificava (o doveva verificare) le relazioni, ma sappiamo tutti com'è: un bug qui, una fretta là, un collega che non ha letto le convenzioni, e il database diventa un far west. Invece se imposti ON DELETE CASCADE o ON DELETE RESTRICT a livello di database, è il sistema stesso che ti protegge.

Con Laravel uso sempre le foreign key constraints nelle migration: un paio di righe che ti salvano da settimane di debugging. Esempio banale ma efficace:

$table->foreignId('user_id')
      ->constrained()
      ->onDelete('cascade');

Semplice, chiaro, sicuro. Se cancelli un utente, tutte le sue prenotazioni vengono eliminate automaticamente (o bloccate, se preferisci). Niente dati orfani, niente query che ritornano null quando non dovrebbero.

Lo stesso vale per i vincoli di unicità, i check constraints, i default values. Sono strumenti che il database ti offre gratuitamente, perché non usarli? Delegare tutta la logica all'applicazione è chiedere guai.

Questione di filosofia (e di manutenzione)

Dietro questi tre errori c'è sempre la stessa mentalità: "il database è solo un contenitore di dati, la logica sta nel codice". Io la penso diversamente. Il database è parte integrante dell'applicazione, con le sue regole, i suoi vincoli, la sua intelligenza.

Quando strutturi bene un database, il codice diventa più semplice. Le query sono chiare, le performance migliori, i bug meno frequenti. E soprattutto, tra sei mesi quando devi aggiungere una funzionalità, non devi prima decifrare un geroglifico.

Nella mia esperienza con gestionali personalizzati e applicazioni web, ho visto progetti salvati da un database ben fatto e progetti affondati da uno fatto male. La differenza non è nella tecnologia che usi (MySQL, PostgreSQL, SQLite... vanno tutti bene se li usi bene), ma in come la usi.

Quindi il mio consiglio, dopo oltre vent'anni di errori fatti e corretti: dedica tempo al database. Progettalo, normalizzalo, indicizzalo. Usa i vincoli. Non dare per scontato che "tanto il codice controlla tutto". Perché il codice ha bug, il database no (se configurato bene).

E se hai dubbi sul tuo database attuale, o stai partendo da zero con un nuovo progetto, parliamone. A volte basta un paio d'ore per evitare mesi di mal di testa. Trovi tutti i miei contatti sul sito, oppure scrivimi direttamente e vediamo come posso aiutarti.