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:

  1. Der tages en transaktion, som vil låse hele tabellen (grundet punkt 2)

  2. Temporal Tables slås fra

  3. En relativ lille mænge af aktuelle såvel som historiske data slettes

  4. Temporal Tables slås til uden validering af datakonsistens

  5. Transaktionen afsluttes

  6. Punkt 1 – 6 gentages indtil slettebatchjobbet har slettet nok data

  7. 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.