geschiedenis rijen beheer in database

De eerste vraag zou moeten zijn:wat zou u met die gegevens doen? Als u geen duidelijke zakelijke eis heeft, doe het dan niet.

Ik heb iets soortgelijks gedaan en na 3 jaar draaien is er ongeveer 20% "geldige gegevens" en de rest is "vorige versies". En het zijn 10 miljoen + 40 miljoen records. In de afgelopen drie jaar hadden we 2 (twee) verzoeken om de geschiedenis van wijzigingen te onderzoeken en beide keren waren verzoeken dwaas - we registreren het tijdstempel van de recordwijziging en we werden gevraagd om te controleren of personen overuren maakten (na 17.00 uur).

Nu zitten we met een te grote database die 80% van de gegevens bevat die niemand nodig heeft.

BEWERKEN:

Omdat je om mogelijke oplossingen vroeg, zal ik beschrijven wat we hebben gedaan. Het is een beetje anders dan de oplossing die u overweegt.

1. Alle tabellen hebben een vervangende primaire sleutel.
2. Alle primaire sleutels worden gegenereerd op basis van een enkele reeks. Dit werkt prima omdat Oracle nummers kan genereren en cachen, dus geen prestatieproblemen hier. We gebruiken ORM en we wilden dat elk object in het geheugen (en het bijbehorende record in de database) een unieke identifier had
3. We gebruiken ORM en toewijzingsinformatie tussen databasetabel en klasse is in de vorm van attributen.

We registreren alle wijzigingen in een enkele archieftabel met de volgende kolommen:

• id (primaire surrogaatsleutel)
• tijdstempel
• originele tafel
• id van originele record
• gebruikers-ID
• transactietype (invoegen, bijwerken, verwijderen)
• record data als varchar2 veld
  • dit zijn feitelijke gegevens in de vorm van veldnaam/waarde-paren.

Ding werkt op deze manier:

• ORM heeft commando's voor invoegen/bijwerken en verwijderen.
• we hebben één basisklasse gemaakt voor al onze bedrijfsobjecten die de opdrachten voor invoegen/bijwerken en verwijderen overschrijft
  • insert/update/delete-commando's creëren een string in de vorm van veldnaam/waarde-paren met behulp van reflectie. Code zoekt naar toewijzingsinformatie en leest veldnaam, bijbehorende waarde en veldtype. Vervolgens maken we iets dat lijkt op JSON (we hebben enkele wijzigingen toegevoegd). Wanneer een tekenreeks wordt gemaakt die de huidige staat van het object vertegenwoordigt, wordt deze in de archieftabel ingevoegd.
• wanneer een nieuw of bijgewerkt object wordt opgeslagen in de databasetabel, wordt het opgeslagen in zijn doeltabel en tegelijkertijd voegen we één record met de huidige waarde in de archieftabel in.
• wanneer het object wordt verwijderd, verwijderen we het uit zijn doeltabel en voegen we tegelijkertijd één record in de archieftabel in met transactietype ="DELETE"

Pro:

• we hebben geen archieftabellen voor elke tabel in de database. We hoeven ons ook geen zorgen te maken over het bijwerken van de archieftabel wanneer het schema verandert.
• compleet archief is gescheiden van "huidige gegevens", dus archief legt geen prestatiehit op aan database. We zetten het op een aparte tablespace op een aparte schijf en het werkt prima.
• we hebben 2 formulieren gemaakt om archief te bekijken:
  • algemene viewer die archieftabel kan weergeven volgens filter op archieftabel. Filtergegevens gebruiker kan invullen op formulier (tijdspanne, gebruiker, ...). We tonen elk record in de vorm veldnaam/waarde en elke wijziging is kleurgecodeerd. Gebruikers kunnen alle versies voor elk record zien en ze kunnen zien wie en wanneer wijzigingen hebben aangebracht.
  • factuurviewer - deze was complex, maar we hebben een formulier gemaakt dat de factuur weergeeft die erg lijkt op het originele factuurinvoerformulier, maar met enkele extra knoppen die verschillende generaties kunnen weergeven. Het kostte veel moeite om dit formulier te maken. Formulier werd een paar keer gebruikt en vervolgens vergeten omdat het niet nodig was in de huidige workflow.
• code voor het maken van archiefrecords bevindt zich in een enkele C#-klasse. Er zijn geen triggers nodig voor elke tabel in de database.
• prestaties zijn erg goed. Op piekmomenten wordt het systeem gebruikt door ongeveer 700-800 gebruikers. Dit is de ASP.Net-toepassing. Zowel ASP.Net als Oracle draaien op één dubbele XEON met 8Gb RAM.

Nadelen:

• Archiefindeling met één tabel is moeilijker te lezen dan een oplossing waarbij er één archieftabel is voor elk van de gegevenstabellen.
• zoeken op niet-id-veld in archieftabel is moeilijk - we kunnen alleen LIKE gebruiken operator op string.

Dus nogmaals, controleer de vereisten voor archief . Het is geen triviale taak, maar de winst en het gebruik kunnen minimaal zijn.