gestione delle righe della cronologia nel database

La prima domanda dovrebbe essere:cosa faresti con quei dati? Se non hai requisiti aziendali chiari, non farlo.

Ho fatto qualcosa di simile e dopo 3 anni di esecuzione c'è circa il 20% di "dati validi" e il resto sono "versioni precedenti". E sono 10 milioni + 40 milioni di record. Negli ultimi tre anni abbiamo ricevuto 2 (due) richieste per indagare sulla cronologia dei cambiamenti ed entrambe le volte le richieste erano sciocche:registriamo l'ora del cambio di record e ci è stato chiesto di controllare se le persone facevano gli straordinari (dopo le 17:00).

Ora, siamo bloccati con un database di grandi dimensioni che contiene l'80% dei dati di cui nessuno ha bisogno.

MODIFICA:

Dal momento che hai chiesto possibili soluzioni, descriverò cosa abbiamo fatto. È un po' diverso dalla soluzione che stai considerando.

1. Tutte le tabelle hanno una chiave primaria surrogata.
2. Tutte le chiavi primarie sono generate da una singola sequenza. Funziona bene perché Oracle può generare e memorizzare nella cache numeri, quindi nessun problema di prestazioni qui. Usiamo ORM e volevamo che ogni oggetto in memoria (e il record corrispondente nel database) avesse un identificatore univoco
3. Utilizziamo ORM e le informazioni di mappatura tra la tabella del database e la classe sono sotto forma di attributi.

Registriamo tutte le modifiche in un'unica tabella di archivio con le seguenti colonne:

• id (chiave primaria surrogata)
• marca temporale
• tabella originale
• id del record originale
• ID utente
• tipo di transazione (inserisci, aggiorna, elimina)
• registra i dati come campo varchar2
  • questi sono dati effettivi sotto forma di coppie nome campo/valore.

Funziona così:

• ORM ha comandi di inserimento/aggiornamento ed eliminazione.
• abbiamo creato una classe base per tutti i nostri oggetti business che sovrascrive i comandi di inserimento/aggiornamento ed eliminazione
  I comandi
  • insert/update/delete creano una stringa sotto forma di coppie nome campo/valore usando la riflessione. Il codice cerca le informazioni sulla mappatura e legge il nome del campo, il valore associato e il tipo di campo. Quindi creiamo qualcosa di simile a JSON (abbiamo aggiunto alcune modifiche). Quando viene creata una stringa che rappresenta lo stato corrente dell'oggetto, viene inserita nella tabella di archivio.
• Quando un oggetto nuovo o aggiornato viene salvato nella tabella del database, viene salvato nella sua tabella di destinazione e allo stesso tempo inseriamo un record con il valore corrente nella tabella dell'archivio.
• quando l'oggetto viene eliminato, lo cancelliamo dalla sua tabella di destinazione e allo stesso tempo inseriamo un record nella tabella di archivio che ha tipo di transazione ="DELETE"

Pro:

• non abbiamo tabelle di archivio per ogni tabella nel database. Inoltre, non dobbiamo preoccuparci di aggiornare la tabella di archivio quando lo schema cambia.
• l'archivio completo è separato dai "dati correnti", quindi l'archivio non impone alcun aumento delle prestazioni sul database. Lo mettiamo in uno spazio tabella separato su un disco separato e funziona bene.
• abbiamo creato 2 moduli per la visualizzazione dell'archivio:
  • visualizzatore generale che può elencare la tabella di archivio in base al filtro sulla tabella di archivio. Filtra i dati che l'utente può inserire nel modulo (intervallo di tempo, utente, ...). Mostriamo ogni record sotto forma di nome campo/valore e ogni modifica è codificata a colori. Gli utenti possono vedere tutte le versioni per ogni record e possono vedere chi e quando ha apportato modifiche.
  • Visualizzatore fatture:questo era complesso, ma abbiamo creato un modulo che mostra la fattura molto simile al modulo di immissione della fattura originale, ma con alcuni pulsanti aggiuntivi che possono mostrare generazioni diverse. Ci sono voluti notevoli sforzi per creare questo modulo. Il modulo è stato utilizzato poche volte e poi dimenticato perché non era necessario nel flusso di lavoro corrente.
• il codice per la creazione di record di archivio si trova in un'unica classe C#. Non sono necessari trigger su ogni tabella nel database.
• le prestazioni sono molto buone. Nelle ore di punta, il sistema è utilizzato da circa 700-800 utenti. Questa è l'applicazione ASP.Net. Sia ASP.Net che Oracle funzionano su un doppio XEON con 8 Gb di RAM.

Contro:

• Il formato di archivio a tabella singola è più difficile da leggere rispetto alla soluzione in cui è presente una tabella di archivio per ciascuna tabella di dati.
• La ricerca nel campo non ID nella tabella di archivio è difficile:possiamo usare solo LIKE operatore sulla stringa.

Quindi, ancora una volta, controlla i requisiti sull'archivio . Non è un compito banale, ma i guadagni e l'utilizzo possono essere minimi.