Cancellazione fisica vs cancellazione logica dei dati

Finalmente dopo lungo tempo trovo il tempo di bloggare qualche "inutile sbrodolata"...

L'altro giorno mi trovavo presso un cliente che, giustamente, lamentava problemi di performance su un applicativo. La discussione è stata piuttosto lunga e si sono toccati tanti temi; fino a che non si arriva alla fatidica domanda che ha fatto scaturire questo post: "Ma questo software utilizza la cancellazione fisica dei dati oppure la cancellazione logica?". "Logica...", rispondo io. E lui: "Per quale motivo è stata fatta questa scelta? Non è che i motivi di questa lentezza sono causati da questa scelta?".

Rapidamente ho dovuto "radunare le mie forze", e ricordarmi tutti i motivi per cui, anni fa, ho intrapreso questa strada come "default" per i miei progetti (con le dovute eccezioni). A seguire, vi riporto quello che i miei 4 neuroni sono riusciti a partorire dopo la riflessione...


«Quando si esegue la progettazione di un sistema che gestisce dati, uno dei primi punti decisionali con cui un analista si deve scontrare è la persistenza delle informazioni, e il loro trattamento “logico” quando le stesse vengono sottoposte alle classiche operazioni di CRUD (“Create”, “Read”, “Update” e “Delete”).

Nonostante i modermi sistemi di database relazionali (opportunamente configurati) siano in grado di tracciare tutti gli eventi occorsi su una base dati, è buona regola gestire a livello applicativo una serie di “caratteristiche” che permettano, a livello funzionale, di mettere a disposizione un meccanismo di semplice “auditing” del dato. 

Sempre restando nell’ambito “relazionale”, ogni tabella presente nel sistema informativo dovrebbe riportare quelle che sono delle caratteristiche sulla data di creazione dell’informazione stessa, la data di ultima modifica, gli utenti applicativi che hanno eseguito la creazione e l’ultimo aggiornamento.

Per operazioni di “inserimento”, “modifica” e “lettura” del dato, tali dati aggiuntivi permettono di tracciare in maniera abbastanza precisa una storia del dato (chiaramente se si vogliono tracciare gli stati intermedi tra il primo e l’ultimo, è necessario un ulteriore supporto). Tuttavia il caso della rimozione del dato, è più complicato: le caratteristiche prima citate sono biunivocamente accoppiate con il dato stesso, quindi la sua rimozione comporta anche la perdita di tali “marker”, non permettendo nemmeno di sapere se quel particolare record è mai stato presente nel sistema.

La soluzione è tuttavia molto semplice, e va catalogata sotto la dicitura di “cancellazione logica” delle informazioni. L’introduzione di un flag boolean (true/false) che determina se il record in questione è attivo nel sistema (quindi valido per i flussi funzionali) oppure è “annullato”, “cancellato”, e “rimosso” dal flusso funzionale stesso. Le informazioni aggiuntive sono preservate e, al momento della cancellazione del dato, viene apposto un “flag” “false” sul campo che rappresenta lo stato di validità del record, contestualmente alla registrazione dell’autore e del momento temporale in cui l’azione di “delete” ha avuto luogo (l’ultima modifica del dato è appunto la sua cancellazione).

Naturalmente è bene prendere in considerazione come l’introduzione di tale “feature” in un sistema informativo comporti dei processi decisionali differenti: ciascuna estrazione dati, deve essere mirata ai record il cui stato di validità è quello “attivo”, tralasciando le informazioni “non attive” che restano nel sistema ma non compartecipano al workflow definito nella soluzione software.

Un’altra possibile problematica legata all'adozione indiscriminata di questo approccio è che, con l’uso del sistema, il numero di record “cancellati” logicamente potrebbe crescere a dismisura, impattando sulle dimensioni della base dati e quindi del sistema stesso. Ma con l’avvento di RDBMS moderni ed ottimizzati, ed un costo inferiore dei supporti di memorizzazione, tale problematica è da ritenersi secondaria, anche se non è da sottovalutarsi in realtà dove la mole di dati trattata è, o potrebbe diventare, considerevole.

D'altra parte è bene ricordare che una cancellazione “logica”, oltre a garantire uno strato minimo di auditing del dato senza necessariamente ricorrere a soluzioni più complesse, permette di porre rimedio a quello che è l’errore umano. L’erronea cancellazione di un’informazione importante presente nel sistema, magari vitale, è facilmente rimediabile senza dover ricorrere al ripristino di una versione precedente della base dati, oppure ricostruire manualmente il dato perso.

Un’altra caratteristica della cancellazione logica che è molto apprezzabile è il fatto che non innesca la funzionalità di “delete cascade” dei database relazionali: poichè i dati rimangono fisicamente sul database, i record associati come chiave esterna al dato in oggetto, non vengono a loro volta rimossi, permettendo il “recupero” prima menzionato con estrema facilità.

Inoltre se il sistema che si sta implementando ha caratteristiche “distribuite” (cioè è dislocato in differenti aree geografiche oppure è composto da moduli con storage differenti), la caratteristica della cancellazione logica è essenziale al fine di permettere una ottimizzata sincronia del dato. Se, per esempio, esistono due sistemi che trattano le medesime informazioni, e hanno necessità di mantenere una particolare anagrafica sincronizzata, è molto semplice che l’uno “segnali” all’altro quando un particolare record è stato rimosso, in modo che la rimozione sia propagata. In scenari con cancellazioni fisiche, tale caratteristica è ugualmente implementabile, ma richiedere un effort maggiore perchè bisogna ragionare in maniera “sottrattiva”, quindi condiderare gli interi domini dati dei due sistemi e calcolare la “differenza” che innescherà l’operazione di sincronizzazione.»

Delirio? Si, ne sono consapevole anche io (e sto cercando di farmi curare, credetemi). Ma sono fermamente  convinto che l'utilizzo della cancellazione logica sui software rappresenti la consueta "mutanda di ghisa", che quelli che fanno il nostro mestiere dovrebbero sempre indossare la mattina appena alzati.

Alla prossima...