Hmm, det tænkte jeg også på.
- At have en tabel pr. tabel-til-behold-revisioner for ville ikke være det store problem for mig personligt, men hey.
- Brugernavn kan beholdes med brugerdefinerede variabler, tror jeg, (efter en sessions start problem noget som
SET @user='someone'
, og brug det. - Så længe der er triggere efter INSERT, UPDATE og DELETE, er det en simpel forespørgsel at hente de forrige/næste værdier, jeg gemmer kun de GAMLE værdier.
Kort sagt, for en tabel med kolonner (a,b,c) ville jeg oprette en tabel med kolonner (user_id,modtime,a,b,c).
Store ulemper:
- batchopdateringer er langsomme (så vælg dine tabeller for at gemme revisioner for omhyggeligt)
- dataduplikering deluxe, du/jeg skal have nok lagerplads
- 'relaterede' data udløser ikke en revision (dvs. ændring af en
group_members
tabel ændrer ikke rigtig engroups
tabel, mens du måske ønsker at beholde det som et tidspunkt forgroups
i stedet for at dykke gennemgroup_members
ændringer.
Alt i alt forekommer det mig at være en god handel, men som jeg sjældent har set det i praksis må være overbevisende grunde til, at det er dårligt, så jeg afventer disse svar.