Penso che tutti noi, prima o poi, nel nostro lavoro ci siamo imbattuti nella temutissima “interpretazione alternativa” del campo di un database. Si tratta di quel fenomeno, spesso dettato dalla fretta (che si sa, è SEMPRE cattiva consigliera) che porta lo sviluppatore ad utilizzare uno o più campi di una tabella in un modo che travalica il loro reale significato. Mi spiego meglio: è il classico “metto NULL nel campo IDImpiegato per segnalare che l’ordine è stato evaso”.
Questa “bestialità” non è solo il segnale di un completo menefreghismo di qualsiasi forma di normalizzazione del database, ma anche la manifestazione della totale assenza di percezione di ciò che viene a crearsi a livello di logica implementativa dell(e) applicazione costruite sul DB.
Elenchiamo per punti le “trappole” in cui si può cadere:
- Il campo è stato creato per soddisfare determinati requisiti, ma in “certi casi” deve essere trattato in un altro modo (lo sa solo chi lo usa, quale sia questo modo…)
- Il campo stesso non può essere soggetto a vincoli di chive esterna, per cui è “fuori controllo”. Se si tratta quindi di un campo di questo tipo sono dolori…
- Il codice dell’applicazione deve essere “field-meaning-aware”, ovvero si deve scrivere del codice (il più delle volte degli IF…:-() per tener conto delle casistiche contemplate dal campo
- Non c’è nessuno “schema” che mappa i “campi” alle “intenzioni”, per cui se (come succede nel 98% dei casi) il database non è documentato e si “perde” il significato dei valori presenti nel database (leggasi: lo sviluppatore che l’ha creato se ne va), l’unica strada percorribile è data da un esame (terribbbbbile!) del codice dell’applicazione che accedeva al database per dedurre l’uso che si faceva del campo
- Se ci sono più applicazioni che accedono allo stesso database, ogni applicazione deve essere sufficientemente “disciplinata” e sapere che in determinati casi, quel campo assume un valore “da interpretare”; non solo: anche tutte le applicazioni future dovranno essere sufficientemente disciplinate e sapere che se per caso non inseriscono i valori “giusti” nel campo da interpretare, potrebbero far collassare le vecchie applicazioni (ARGH!)
Dall’analisi dei punti, e ce ne sarebbero molti altri, penso si intuisca come una semplice soluzione temporanea sia destinata a trasformarsi in un inferno permanente, e tutto questo per evitare di dover creare un campo in una tabella o un’altra tabella per gestire in modo più corretto un fenomeno.
Il più delle volte questo comportamento si presenta quando il requisito osservato non era stato contemplato in fase di progettazione. Ecco perchè, ancora una volta, la fase di progettazione ed una disamina il più possibile accurata dei requisiti rappresenta la chiave per un successo dei progetti software. Inoltre, vorrei osservare ancora una cosa: è sempre possibile che qualcosa non sia stato contemplato in fase di progettazione, perchè il cliente non l’aveva chiesto o perchè al tempo non faceva parte del business domain della soluzione. Una progettazione accurata senza trade-off, basata su solide basi di Database Normalization e Object Oriented Design, spingerà sempre il nostro progetto in una direzione di facile estendibilità futura.