Jeg har tidligere arbejdet i et firma hvor vi brugte mange soft-delete (eller som det hedder i salgsbrochuren - Fuldt revisionsspor), dvs. man sletter ikke i databasen, men markerer istedet rækken for slettet. I vores tilfælde blev slettetidspunktet markeret, så objektets tilstand kunne genskabes på forskellige valørdatoer. De første man lægger mærke til er naturligvis at databasen vokser hurtigt og at alle queries indeholder 'DeletionTime NOT NULL'. Det var praksis og påkrævet af revisorer.

Man kan mene mange ting om soft-delete og Frans Bouma mener at Soft-deletes are bad. Inden vi ser lidt nærmere på hans løsningsforslag, så lad mig give ham ret i at, hvis du ikke har revisorer på nakken, så bør du nok finde på en anden løsning end soft-deletes. Gammelt data er trods alt.. ja, gammelt. Jeg ved godt at vi lever i Google-tid og man bare kan søge igennem alt, men lader du Google indeksere dine business data?

Vi har allerede etableret et behov for at bevare data af juridiske grunde, men det er også værd at nævne at data forbliver slettet. Gammelt data bruges ikke til at "spole" objektets tilstand tilbage ved at "undelete" data, altså fjerne slettetidspunktet i databasen. Derimod oprettes en ny linie som en kopi af den gamle. Ellers ville vi miste det fulde revisionsspor. Vi er ikke i det Frans Bouma kalder tilfælde to (men beskriver først). Det er også noget rod.

En naturlig løsning er at arkivere gammelt data, som man arkiverer gamle emails (eller hvordan er det nu lige er man får håndteret dem?). Frans Bouma foreslår at bruge database triggers. En delete trigger kan kopiere det slettede data over i anden tabel. Et forslag som jeg ikke kan stå 100% bag. Jeg kan se ideen i at kopiere slettet data over
i en anden tabel. Det er alligevel oftest, at man kun skal bruge de aktuelle data og i de tilfælde hvor man skal se gammelt data vil det kunne klares med et view.

Det er database triggeren som giver mig problemer. Der er mange gode og dårlige grunde til at bruge triggers eller lade være, men min helt store anke i dette tilfælde er manglende triggers. Hvis man får slettet triggeren fra database så får man ingen fejlbeskeder. Uden at vide det kan man få slettet en masse data som burde være kopieret. Man opdager det først når man skal bruge de gamle data. En stored procedure ville kunne gøre det samme og man vil helt sikkert opdage hvis den manglede.

Jeg vil mene at soft-deletes har deres plads, specielt for enterprise data. Men derfor er det stadig tilladt at organisere sine data bedst muligt. Bare lov mig at du ikke bruger en delete trigger som er kritisk for dine data.