Hej!

Har en databas med ca 50000 poster i. Under ett par månader vill jag ha en versionshantering på tabellen så man i efterhand kan redovisa aktuella giltiga värden för valda dagar.

Dagligen kan poster revideras, läggas till och tas bort.

Någon som har ideer på hur man löser detta.

Vad jag tänker mej, är att varje dag man går in och jobbar i databasen så skapar man en ny version. När man sedan går in på en post och ändrar någon data så skall befintlig post inte ändras, utan en kopia av bef. post skall skapas som ändringen görs i. Den nya posten är då den giltiga för den dagen, tillsammans med alla tidigare poster som inte ändrats exkl. den ursprl. posten som reviderades.

Har ni några tips på hur man löser detta?

Att ta en kopia på tabellen med 50000 poster i kanske flera gånger dagligen är ingen aktuell lösning...

Tacksam för tips!

Databasen är en Access 2000 databasa

Att kopiera hela databasen låter inte som en bra lösning. Jag skulle hellre hanterat det i samma tabell eller möjligen en extra tabell för temporärdata. När användaren gör UPDATE tar du i stället en kopia på raden som får en ny timestamp (datum, tid, löpnr). Att backa till föregående version gör du helt enkelt genom att igen kopiera en rad med en viss timestamp. Databasen kommer bli stor men det ska normalt sett inte vara några problem i din stoleksordning så länge du har vettiga index i tabellerna. Att lagra undan endast de fält som har ändrats (helt normaliserat) vore förstås optimalt i teorin; men det skulle bli onödigt komplext.

Kan du ändra i tabellen? Om det är möjligt så är en idé att göra såhär:
1) Din id-kolumn (eller vad du nu har) ska _inte_ vara unik
2) Skaffa en timestamp-kolumn
3) Skaffa en "deleted"-kolumn (en boolean för om posten är raderad eller inte)

Sedan blir det lite nya regler:
1) När du ska sätta in en ny post så sätter du id till ett nytt id (eller har autoräknande), sätter timestamp till dagens datum och tid, samt sätter deleted till false
2) När du ska ändra en post så sätter gör du istället en insert, sätter id till samma id som på posten du "ändrar", sätter timestamp till dagens datum och tid, sätter deleted till false, samt kopierar över alla "gamla" värden + det du ändrade
3) När du ska ta bort en post så gör du även nu en insert, sätter id till samma id, sätter timestamp, men sätter deleted till true

Sedan när du vill titta i det hela så gäller följande:
1) Plocka för varje id ut den timestamp som är högst
2) Sortera bort alla som har deleted=true
3) Gör vad du vill med datan

Om du vill titta vid en viss tidpunkt gäller följande:
1) Plocka för varje id ut den timestamp som är högst, men <= den tidpunkten
2) Sortera bort alla som har deleted=true
3) Gör vad du vill med datan

Grejjen är alltså att man aldrig ändrar eller tar bort saker, man behåller rubb och stubb. Eftersom att man har timestamp-kolumnen så kan man enkelt titta på hur det ser ut just nu, eller hur det såg ut vid en viss tidpunkt.

Exempel:
Id | Dat | En timestamp här | deleted
1 | Kalle | 2009-01-19 13:37 | false
1 | Arne | 2009-01-20 13:37 | false
2 | Häst | 2009-01-20 14:00 | false
1 | Maja | 2009-01-21 13:37 | false
1 | Maja | 2009-01-22 13:37 | true

Om vi tittar på nuläget så får vi:
1 | Maja | 2009-01-22 13:37 | true
2 | Häst | 2009-01-20 14:00 | false

Observera då att #1 är markerade "deleted" så vi kommer se:
2 | Häst | 2009-01-20 14:00 | false

Om vi tittar vid t.ex. 2009-01-20 15:00:
1 | Arne | 2009-01-20 13:37 | false
2 | Häst | 2009-01-20 14:00 | false

Om vi tittar vid t.ex. 2009-01-19 14:00:
1 | Kalle | 2009-01-19 13:37 | false

Hänger du med?

(Nackdelen är att det kan blir mycket ändringar i sql-frågor om det redan finns mycket kod som jobbar mot tabellen, men, men)