Non mi stancherò mai di ripeterlo anche perchè ogni giorno vedo i risultati di quello che accade se chi sviluppa applicazioni non applica una regola di base ma per qualche stupido motivo mai seguita.
I dati che la vostra applicazione utilizza e che mette in un database devono essere validati dal database. Oggi in molti "consulenti" non la pensano così, perchè il database "è un semplice file binario", aiutando in questo modo i loro clienti ad avere presto o tardi numerosi problemi con i loro dati. Certo nel momento dei problemi questi consulenti non ci sono, probabilmente in giro a rimpirsi la bocca raccontando idiozie sui database, parlando di argomenti di cui sono perfettamente ignoranti.
In questi giorni sono stato da un cliente che ha dovuto re-inviare le fatture e le bolle di un notevole periodo di tempo perchè qualcuno ha inserito nell'applicazione dei dati che non avrebbero mai dovuto essere inseriti in quanto non esistenti nella realtà! Nella fattispecie sono stati inseriti ordini per un prodotto non vendibile in un certa area.
Il database è complesso (e mal fatto) e la logica di business (di validazione dei dati, non logica di business "complessa" che invece deve essere corretamente implementate nelle applicazioni) è stata inserita solamente nell'applicazione di gestione ordini. Secondo tutti i conivolti, quello che è avvenuto avrebbe dovuto essere impossibile perchè effettivamente l'applicazione (piuttosto complessa) preveniva questa possibilità in quanto validava i dati. Ed infatti era vero.
Vero tranne che in un particolare caso, dimenticato da tutti gli sviluppatori ma non dagli utilizzatori che invece lo utilizzavano tutti i giorni! Il risultato di questa scelta architetturale sono due giorni di lavoro buttati nella spazzatura.
Ora ho obbligato il cliente a mettere una serie di logiche di validazione (che sono logiche di business, le uniche che devono essere implemente obbligatoriamente sul database) che impediscono l'introduzione di dati incoerenti nel database, proteggendolo cosi da errori o dimenticanze applicative.
E la morale è proprio questa: il database è quello che contiene i dati dell'azienda e si si fa un'errore non si può semplicemente fare un undo. Dobbiamo quindi proteggerli, a tutti i costi, altrimenti avremo diversi problemi che prima o poi verranno al pettine. Dopo aver definito corretamente i costraint sul database ci dobbiamo preoccupare di implementarli anche nelle applicazioni che scriviamo, in modo da renderle il più user friendly possibili, ma solo per quest'ultimo motivo, non per altro! Nel caso in cui le nostre applicazioni fossero modificate da altri, senza lo nostra sensibilità in termini di validazione dei dati, il nostro database deve essere in grado di proteggersi "da solo" da questi sviluppatore meno sensibili.
La qualità dei dati nel database non deve poter essere un fatto aleatorio, lasciato al "buon senso" degli sviluppatori. Non tutti ne sono provvisti.
Usate quindi tutti i constraint, trigger (se proprio non potete farne a meno), stored procedure e quant'altro che vi assicuri che se un dato è sbagliato (e per dato intendo un ordine o un cliente non solamente il singolo valore come potrebbe essere il CAP) questo non potrai mai, in nessun caso essere accettato dal database.
Proteggete voi stessi ed i vostri dati. Lavorerete molto meglio. Ed attenti ai profeti del "il database è superato"....