Effektiv styring af dataændringer

I modsætning hertil kan den traditionelle database, vi bruger uden tidsmæssige funktioner, kaldes en aktuel database .

I en aktuel database , hvis du forsøger at implementere tidsmæssig støtte, kan du fejle på mange måder med forskellige tilgange:

• Et-bord tilgang. Når du skal foretage ændringer, laver du UPDATEs på dine originale poster, og medmindre du har en form for hjemmelavet trigger/audit-logik, er historiesporet fraværende. Selvom du har en revisions-/ændringslog, er du nødt til at grave noget grimt for at rekonstruere ændringshistorikken.

• To-bord tilgang. I stedet for at foretage ændringer på stedet, opdeler du dine data i to tabeller, en med basis/oprindelige poster (f.eks. booking) og en anden tabel for dine ændringer/ændringer/deltaer. Så har du i det mindste dine originale data bevaret, men igen skal du skrive kompleks logik for at se de originale data med ændringer lagt på. Det bliver endnu værre, hvis du kun vil have nogle af de anvendte ændringer.

• Den forudberegnede resulterende tabeltilgang . Du beholder 3 eller flere tabeller:basisposterne, ændringerne og også en tabel, der forsøger altid at have resultatet (holder ajourført basis + ændringer). Held og lykke med at skrive triggere og procedurer til at udføre denne beregning, når du laver INSERTs , og himlen hjælper dig, hvis en UPDATE eller DELETE er nødvendig. Opsætningen er skrøbelig og kan bryde ud af synkronisering, såsom deadlocks og rollback. Hvis du ikke gør dette i DB'en med triggere/procedurer, kan du prøve at implementere resulterende beregning i applikationskoden, men held og lykke med det - og det kan blive grimt med multi-threaded forbrugere. Og stadig har du ikke let adgang til resultater med kun nogle ændringer anvendt.

Konklusion: Hvis du ikke er begrænset til MySQL, bør du virkelig overveje at bruge en DB, der har indbygget tidsmæssig support. Ellers vil du genimplementere hjulet.