Her er én måde at gøre det på:
Grundlæggende ændrer eller sletter vi aldrig de eksisterende data. Vi "modificerer" den ved at oprette en ny version. Vi "sletter" det ved at sætte flaget SLETTET.
For eksempel:
- Hvis produktet ændrer prisen, indsætter vi en ny række i PRODUCT_VERSION, mens gamle ordrer holdes forbundet med den gamle PRODUCT_VERSION og den gamle pris.
- Når køber ændrer adresse, indsætter vi blot en ny række i CUSTOMER_VERSION og linker nye ordrer til den, mens de gamle ordrer er knyttet til den gamle version.
- Hvis produktet slettes, sletter vi det ikke rigtigt - vi indstiller blot flaget PRODUCT.DELETED, så alle de ordrer, der historisk er foretaget for det pågældende produkt, forbliver i databasen.
- Hvis kunden slettes (f.eks. fordi han anmodede om at blive afregistreret), skal du indstille flaget CUSTOMER.DELETED.
Forbehold:
- Hvis produktnavnet skal være unikt, kan det ikke håndhæves deklarativt i modellen ovenfor. Du bliver enten nødt til at "promovere" NAVNET fra PRODUCT_VERSION til PRODUCT, gøre det til en nøgle der og opgive evnen til at "udvikle" produktets navn eller håndhæve unikhed på kun den seneste PRODUCT_VER (sandsynligvis gennem triggere).
- Der er et potentielt problem med kundens privatliv. Hvis en kunde slettes fra systemet, kan det være ønskeligt at fjerne dens data fysisk fra databasen, og blot at indstille KUNDE.SLETT vil det ikke gøre. Hvis det er en bekymring, skal du enten slette de privatlivsfølsomme data i alle kundens versioner, eller alternativt afbryde eksisterende ordrer fra den rigtige kunde og gentilslutte dem til en særlig "anonym" kunde, og derefter fysisk slette alle kundeversioner.
Denne model bruger en masse identificerende relationer. Dette fører til "fede" fremmednøgler og kan være lidt af et lagringsproblem, da MySQL ikke understøtter avanceret indekskomprimering (i modsætning til f.eks. Oracle), men på den anden side InnoDB altid grupperer dataene på PK, og denne klyngedannelse kan være gavnlig for ydeevnen. Desuden er JOINs mindre nødvendige.
Tilsvarende model med ikke-identificerende relationer og surrogatnøgler ville se sådan ud:
