Strategia efficace per lasciare una traccia di controllo/cronologia delle modifiche per le applicazioni DB?

Question

Quali sono alcune strategie con cui le persone hanno avuto successo per mantenere una cronologia delle modifiche per i dati in un database abbastanza complesso.Una delle applicazioni che utilizzo e per la quale sviluppo spesso potrebbe davvero trarre vantaggio da un modo più completo di tenere traccia di come i record sono cambiati nel tempo.Ad esempio, al momento i record possono avere una serie di timestamp e campi utente modificati, ma al momento non disponiamo di uno schema per registrare più modifiche, ad esempio se un'operazione viene ripristinata.In un mondo perfetto, sarebbe possibile ricostruire il record così com'era dopo ogni salvataggio, ecc.

Alcune informazioni sul DB:

• Deve avere la capacità di crescere di migliaia di record a settimana
• 50-60 tavoli
• Le tabelle principali revisionate possono contenere diversi milioni di record ciascuna
• Quantità ragionevole di chiavi esterne e indici impostati
• Utilizzando PostgreSQL 8.x

Answer 1

In passato ho utilizzato i trigger per costruire la registrazione di aggiornamento/inserimento/eliminazione db.

È possibile inserire un record ogni volta che una delle azioni di cui sopra viene eseguita su una tabella specifica in una tabella di registrazione che tiene traccia dell'azione, dell'utente db che l'ha eseguita, del timestamp, della tabella su cui è stata eseguita e del valore precedente.

Probabilmente esiste una risposta migliore, poiché ciò richiederebbe di memorizzare nella cache il valore prima che venga eseguita l'eliminazione o l'aggiornamento effettivo, credo.Ma potresti usarlo per eseguire i rollback.

Answer 2

Una strategia che potresti utilizzare è MVCC, Multi-Value Concurrency Control.In questo schema, non esegui mai aggiornamenti a nessuna delle tue tabelle, fai solo inserimenti, mantenendo i numeri di versione per ciascun record.Ciò ha il vantaggio di fornire un'istantanea esatta da qualsiasi momento e inoltre elude completamente i problemi di blocco degli aggiornamenti che affliggono molti database.

Ma costituisce un database enorme e seleziona tutti richiede una clausola aggiuntiva per selezionare la versione corrente di un record.

Answer 3

Se stai usando Hibernate, dai un'occhiata a JBoss Envers.Dalla home page del progetto:

Il progetto Envers mira a consentire un facile controllo delle versioni delle classi JPA persistenti.Tutto quello che devi fare è annotare la tua classe persistente o alcune delle sue proprietà, di cui vuoi modificare la versione, con @Versioned.Per ogni entità con versione verrà creata una tabella che conterrà la cronologia delle modifiche apportate all'entità.È quindi possibile recuperare ed eseguire query sui dati storici senza troppi sforzi.

Questo è in qualche modo simile a L'approccio di Eric, ma probabilmente molto meno sforzo.Tuttavia, non so quale linguaggio/tecnologia usi per accedere al database.

Answer 4

L'unico problema con l'utilizzo dei trigger è che aumenta il sovraccarico delle prestazioni di qualsiasi inserimento/aggiornamento/eliminazione.Per una maggiore scalabilità e prestazioni, è preferibile mantenere la transazione del database al minimo.Il controllo tramite trigger aumenta il tempo necessario per eseguire la transazione e, a seconda del volume, può causare problemi di prestazioni.

un altro modo è esplorare se il database fornisce un modo per estrarre i log "Ripeti" come nel caso di Oracle.I log di ripetizione sono ciò che il database utilizza per ricreare i dati nel caso in cui fallisca e debba essere ripristinato.

Answer 5

Similmente a un trigger (o anche con) è possibile fare in modo che ogni transazione attivi un evento di registrazione in modo asincrono e che un altro processo (o semplicemente thread) gestisca effettivamente la registrazione.Ci sarebbero molti modi per implementarlo a seconda della tua applicazione.Suggerisco di fare in modo che l'applicazione attivi l'evento in modo che non causi un carico inutile sulla prima transazione (che a volte porta a blocchi dai registri di controllo a cascata).

Inoltre, potresti essere in grado di migliorare le prestazioni del database primario mantenendo il database di controllo in una posizione separata.

Answer 6

Utilizzo SQL Server, non PostgreSQL, quindi non sono sicuro che funzionerà per te o no, ma Pop Rivett ha pubblicato un ottimo articolo sulla creazione di una traccia di controllo qui:Domande frequenti su SQL Server N. 5 di Pop Rivettat:Fai un salto sulla pista di controllo

Crea una tabella di controllo, quindi crea un trigger per ogni tabella che desideri controllare.

Suggerimento:utilizzo Codesmith per creare i tuoi trigger.