Den gode GDPR-sletning (Temporal Tables)
Baggrund
Da applikationsarkitekturen for de nye forretningsdomæner blev fastlagt i forbindelse med udvikling af CV i JobSearch, blev det fastlagt, at vi skulle bruge Temporal Tables. I den forbindelse blev både fordele og ulemper vurderet, hvor en af ulemperne ville være en mere besværlig sletning af data i forhold til GDPR.
Det blev på daværende tidspunkt vurderet, at dette kunne lade sig gøre. Efterfølgende er der blevet lavet slettebatchjob til de nye forretningsdomæner, hvor princippet er, at både aktuelle data såvel som historiske slettes i Trunks af en relevante størrelse. Dette for at kunne deaktivere og genaktivere Temporal Tables i én og samme transaktion.
Sletning i Trunks
Slettebatchjob til de nye forretningsdomæner implementeres så både aktuelle data og historiske slettes i Trunks af en relevante størrelse. Dette for at kunne deaktivere og genaktivere Temporal Tables i en og samme transaktion.
Sletning sker derfor efter følgende mønster:
Der tages en transaktion, som vil låse hele tabellen (grundet punkt 2)
Temporal Tables slås fra
En relativ lille mænge af aktuelle såvel som historiske data slettes
Temporal Tables slås til uden validering af datakonsistens
Transaktionen afsluttes
Punkt 1 – 6 gentages indtil slettebatchjobbet har slettet nok data
Temporal Tables skal være slået til, når batchjobbet er kørt
Fremtidig sletning efter dette mønster
De nye forretningsdomæner er blevet, og vil fortsat blive, udviklet med Temporal Tables, med mindre andet bliver besluttet. Dette betyder også, at vi rent forretningsmæssigt også skal kunne slette data fra disse tabeller, hvilket bør ske efter ovenstående mønster.