Avete presente quando cercate di fare debugging su un database e scoprite che una colonna che doveva contenere solo numeri è diventata un cimitero di stringhe, booleani e pattern casuali? Ecco, SQLite per anni è stato un po’ come quel tuo amico che dice ‘va tutto bene’ mentre la sua vita sta andando in pezzi.
Il punto è che la filosofia classica di SQLite è la ‘flexible typing’. In pratica, il motore ti permette di infilare quasi tutto ovunque. Vuoi mettere ‘ciao’ in una colonna `INTEGER`? Succede. Vuoi creare una colonna con un tipo che non esiste nemmeno, tipo `BLOBB` (con due B)? SQLite ti sorride e procede senza fiatare. È una libertà che, a prima vista, sembra fantastica, ma che in produzione si trasforma nel classico incubo da ‘perché il modulo calcolo crasha alle tre di notte?’.
La buona notizia (per chi ha il sangue freddo e odia i bug silenti) è che esiste una funzione chiamata ‘Strict Tables’. Basta aggiungere la parola chiave `STRICT` alla fine della definizione della tabella e — boom! — il party finisce. Se provi a inserire del testo in una colonna numerica, SQLite smette di fare il compiacente e ti lancia un errore. Fine della storia. Niente più tipi di dato inventati sulla fly o tipi ‘fantasma’ che non corrispondono alla realtà.
Certo, non è tutto rose e fiori. Se hai già un database pieno di spazzatura, passare al mode ‘strict’ non è un semplice click. Devi creare una nuova tabella, migrare i dati, pulire il disastro e sperare che il processo di `INSERT INTO … SELECT` non esploda perché hai trovato un altro valore illegale nascosto in un angolo remoto. È un lavoro sporco, lo so, ma è il prezzo da pagare per la sanità mentale.
E poi c’è la polemica interna. I developer di SQLite hanno una loro pagina dedicata che difende il ‘flexible typing’, sostenendo che la flessibilità sia un punto di forza per casi d’uso particolari, come i magazzini di chiavi-valore o l’importazione di CSV sporchi. Io dico che è un po’ come dire che il caos è una forma di ordine avanzato. Può andare bene per un esperimento di laboratorio, ma quando devi costruire qualcosa di serio, vuoi che il tuo database ti fermi quando stai facendo una cavolata.
In conclusione: se usate SQLite 3.37.0 o versioni successive, smettete di giocare a Risiko con i tipi di dato. Usate le `STRICT tables`. Sono semplici, sono chiare e, soprattutto, vi evitano di dover passare il weekend a rintracciare quel maledetto valore ‘garbage’ che ha rotto tutto. Se volete ancora la libertà totale, usate il tipo `ANY`, ma non lamentatevi se poi il vostro schema sembra un set di LEGO mescolato con pezzi di un motore diesel.
Source: Prefer strict tables in SQLite