Tre errori con i database che vedo ogni settimana

Settimana scorsa mi ha chiamato il titolare di un'officina meccanica qui vicino a Trento. Il suo gestionale delle pratiche auto andava sempre più lento, fino a bloccarsi del tutto quando cercava di stampare le fatture del mese. "Non capisco, funzionava benissimo fino a sei mesi fa", mi ha detto sconsolato.

Gli ho dato un'occhiata al database. 847.000 righe in una tabella di log che nessuno aveva mai pensato di pulire. Ogni singola operazione registrata dall'inizio dei tempi, incluse le prove fatte dal programmatore precedente. Risultato: query che prima impiegavano millisecondi ora ne prendevano decine di secondi.

Questo è solo uno dei tre errori classici che vedo praticamente ogni settimana quando lavoro su software gestionali su misura per aziende del territorio. Te li racconto perché, se hai un'applicazione web o un gestionale, è probabile che almeno uno di questi problemi ce l'abbia anche tu.

Primo errore: il database che non dimentica mai nulla

L'errore dell'officina è più comune di quanto pensi. Molti sviluppatori (io stesso agli inizi) creano tabelle per registrare ogni evento: login degli utenti, modifiche ai dati, operazioni varie. Sacrosanto per il debugging e l'audit. Il problema è che nessuno si ricorda di fare pulizia.

Ho visto database con milioni di righe di log di sessioni utente vecchie di anni. Oppure tabelle che tengono traccia di ogni singolo accesso a una pagina, senza mai cancellare niente. La conseguenza? Il database cresce a dismisura, le query rallentano, i backup diventano giganteschi e costosi.

La soluzione che applico sempre nei miei progetti Laravel è semplice: archivio i dati vecchi in tabelle separate o, se proprio non servono più, li cancello con un comando schedulato. Per esempio:

// In app/Console/Kernel.php
protected function schedule(Schedule $schedule)
{
    // Cancella i log più vecchi di 90 giorni ogni notte
    $schedule->call(function () {
        DB::table('activity_logs')
            ->where('created_at', 'customer->name; // Query separata!
}

// GIUSTO - una query sola con join
$ordini = Order::with(['customer', 'items', 'shipping'])->get();
foreach($ordini as $ordine) {
    echo $ordine->customer->name; // Nessuna query extra
}

Pagina passata da 20 secondi a 200 millisecondi. Il cliente felice, io pure. Quando sviluppo web app su misura, dedico sempre tempo a ottimizzare le query più usate. Vale la pena anche installare Laravel Telescope in sviluppo: ti fa vedere in tempo reale quali query stanno massacrando il tuo database.

Terzo errore: indici? Cosa sono gli indici?

Questo è il mio preferito perché l'ho fatto anch'io per anni all'inizio. Crei le tue tabelle, definisci i campi, tutto funziona. Poi il progetto cresce, i dati aumentano, e improvvisamente le ricerche diventano lentissime.

Il problema sono gli indici mancanti. O meglio, la mancanza di indici sulle colonne che usi per filtrare o ordinare i dati.

Mi è capitato con un gestionale per una scuola di lingue. Avevano una tabella con migliaia di iscrizioni ai corsi. Quando cercavano gli studenti di un certo corso, la query impiegava secondi. Guardando la tabella ho visto che il campo course_id non aveva nessun indice. MySQL doveva scandire tutte le righe una per una.

Aggiunto l'indice, query passata da 3 secondi a 50 millisecondi:

// Nella migration Laravel
Schema::table('enrollments', function (Blueprint $table) {
    $table->index('course_id'); // Indice su colonna usata spesso
    $table->index(['course_id', 'student_id']); // Indice composto
});

La regola è semplice: se una colonna la usi spesso in WHERE, ORDER BY o JOIN, probabilmente ha bisogno di un indice. Occhio però a non esagerare: troppi indici rallentano INSERT e UPDATE. Come sempre nella programmazione, è questione di equilibrio.

Una cosa che faccio sempre nei miei progetti, sia che si tratti di e-commerce a Trento che di gestionali complessi, è analizzare le slow query dopo qualche mese di utilizzo reale. MySQL e PostgreSQL hanno strumenti per registrare le query lente, ti basta attivarli e vedere cosa emerge.

Il database è come la cantina di casa

Sai cosa hanno in comune tutti e tre questi errori? La mancanza di manutenzione. Il database è come la cantina di casa: all'inizio è ordinata e funzionale, poi con gli anni si riempie di cose inutili che occupano spazio e rendono difficile trovare quello che serve.

La differenza è che la cantina la pulisci una volta all'anno (forse), mentre il database di un gestionale andrebbe monitorato costantemente. Non serve farci chissà cosa: un po' di pulizia automatica dei vecchi dati, query ottimizzate fin dall'inizio, e indici nei posti giusti.

Nella mia esperienza, i problemi più grossi nascono sempre da piccole sviste accumulate nel tempo. Quel log che nessuno cancella, quella query fatta male ma che "tanto per ora va", quell'indice che ti dimentichi di aggiungere. Poi un giorno il gestionale va in tilt proprio quando serve di più.

Se hai un'applicazione web o un software gestionale e ultimamente va più lento del solito, probabilmente c'è uno di questi tre problemi sotto. Oppure tutti e tre insieme, come mi è capitato di vedere più volte. Se vuoi, posso darti un'occhiata e dirti esattamente cosa sta succedendo. Scrivimi pure, di solito basta poco per rimettere le cose a posto.