Den första frågan bör vara:vad skulle du göra med den informationen? Om du inte har tydliga affärskrav, gör det inte.
Jag gjorde något liknande och efter 3 års körning finns det cirka 20% av "giltiga data" och resten är "tidigare versioner". Och det är 10 miljoner + 40 miljoner rekord. Under de senaste tre åren hade vi 2 (två) förfrågningar om att undersöka förändringshistorik och båda gångerna var förfrågningarna dumma - vi registrerar tidsstämpel för rekordändring och vi ombads kontrollera om personer arbetade övertid (efter 17.00).
Nu har vi fastnat för en överdimensionerad databas som innehåller 80 % av data som ingen behöver.
EDIT:
Eftersom du bad om möjliga lösningar, ska jag beskriva vad vi gjorde. Det är lite annorlunda än lösningen du funderar på.
- Alla tabeller har surrogat primärnyckel.
- Alla primärnycklar genereras från en enda sekvens. Detta fungerar bra eftersom Oracle kan generera och cache-nummer, så inga prestandaproblem här. Vi använder ORM och vi ville att varje objekt i minnet (och motsvarande post i databasen) skulle ha en unik identifierare
- Vi använder ORM och kartläggningsinformation mellan databastabell och klass är i form av attribut.
Vi registrerar alla ändringar i en enda arkivtabell med följande kolumner:
- id (surrogat primärnyckel)
- tidsstämpel
- originaltabell
- ID för originalposten
- användar-id
- transaktionstyp (infoga, uppdatera, ta bort)
- spela in data som varchar2-fält
- detta är faktiska data i form av fältnamn/värdepar.
Saken fungerar så här:
- ORM har kommandon för att infoga/uppdatera och ta bort.
- vi skapade en basklass för alla våra affärsobjekt som åsidosätter kommandon infoga/uppdatera och ta bort
- infoga/uppdatera/ta bort kommandon skapar en sträng i form av fältnamn/värdepar med hjälp av reflektion. Koden söker efter mappningsinformation och läser fältnamn, tillhörande värde och fälttyp. Sedan skapar vi något som liknar JSON (vi har lagt till några modifieringar). När en sträng som representerar objektets nuvarande tillstånd skapas, infogas den i arkivtabellen.
- när ett nytt eller uppdaterat objekt sparas i databastabellen, sparas det i hans måltabell och samtidigt infogar vi en post med aktuellt värde i arkivtabellen.
- när objekt tas bort, tar vi bort det från hans måltabell och samtidigt infogar vi en post i arkivtabellen som har transaktionstyp ="DELETE"
Pro:
- vi har inte arkivtabeller för varje tabell i databasen. Vi behöver inte heller oroa oss för att uppdatera arkivtabellen när schemat ändras.
- komplett arkiv är separerat från "aktuella data", så arkivet påtvingar ingen prestandaträff på databasen. Vi lägger det på separat tabellutrymme på separat disk och det fungerar bra.
- vi skapade två formulär för visning av arkiv:
- allmän visningsprogram som kan lista arkivtabell enligt filter på arkivtabell. Filtrera data användaren kan ange på formuläret (tid, användare, ...). Vi visar varje post i form av fältnamn/värde och varje ändring är färgkodad. Användare kan se alla versioner för varje post och de kan se vem och när som gjort ändringar.
- fakturavisare - den här var komplex, men vi skapade ett formulär som visar fakturan mycket lik den ursprungliga fakturainmatningsblanketten, men med några extra knappar som kan visa olika generationer. Det tog stor ansträngning att skapa denna form. Form användes några gånger och glömdes sedan bort eftersom det inte behövdes i nuvarande arbetsflöde.
- koden för att skapa arkivposter finns i en enda C#-klass. Det finns inget behov av triggers på varje tabell i databasen.
- prestanda är mycket bra. Vid rusningstid används systemet av cirka 700-800 användare. Detta är ASP.Net-applikationen. Både ASP.Net och Oracle körs på en dubbel XEON med 8 Gb RAM.
Nackdelar:
- Enkeltabells arkivformat är svårare att läsa än lösning där det finns en arkivtabell för var och en av datatabellerna.
- sökning på icke-id-fält i arkivtabellen är svårt - vi kan bara använda
LIKEoperator på sträng.
Så återigen, kontrollera kraven för arkivering . Det är ingen trivial uppgift, men vinsterna och användningen kan vara minimala.