Migliore implementazione per un modello di dati completamente verificabile?

Question

Il mio requisito è per un modello di dati in cui viene conservata una traccia di controllo completa per le modifiche a ogni attributo di ogni oggetto. Anche le definizioni degli oggetti sono fluide: nuovi attributi possono apparire o scomparire nel tempo. Questo percorso di controllo vivrà separatamente dai database originali, pertanto un modello di controllo basato su trigger non funzionerà.

In un database relazionale, posso implementarlo con un'unica grande tabella ATTRIBUTE_HISTORY che registra ogni singola modifica a ciascun attributo, con campi di timestamp e responsabilità appropriati.

La mia domanda: sono uno dei nuovi modelli di storage (BigTable, HBase, CouchDB, archivi RDF, ecc.) Superiori a un RDBMS per questo scopo?

Answer 1

È anche possibile creare un sistema di registrazione nel codice dell'applicazione. Registra le chiamate a tutte le funzioni che modificano il database e si traducono in un COMMIT riuscito.

Rispondi alla tua domanda: no, basta usare un RDBMS. Sarà più facile eseguire query sul registro.

Answer 2

Non vedo alcun motivo per cui un trigger non possa fare riferimento a un database diverso. Tuttavia, tutte le modifiche fallirebbero se quel database non fosse disponibile, il che potrebbe essere un problema se il database di controllo si trova su un altro server e la conectin non funziona. Ma il nostro controllo è tramite trigger e abbiamo un database di audit separato.

Answer 3

Non credo che un particolare paradigma di database possa essere considerato superiore a qualsiasi altro per un registro di controllo. Non è tanto un problema di modello di dati quanto un problema di registrazione e può essere considerato in qualche modo ortogonale all'archivio dati.

Ciò detto CouchDB può essere configurato per non eliminare mai vecchie versioni di documenti. Con l'aggiunta di un timestamp e possibilmente un campo utente per ogni documento, è possibile utilizzare la funzione per mantenere automaticamente un'intera cronologia di tutti gli oggetti mai archiviati nel db. Questa potrebbe essere la configurazione più semplice possibile per la registrazione di controllo che potresti ottenere in un database.

Per quanto riguarda gli altri, non so quale tipo di supporto potrebbero avere su questo.

Avvertenze:

(Si potrebbe anche seguire un mai cancellare strategia per oggetti nel db e proprio marchio oggetti eliminati invece)

(Per un RDBMS la soluzione più semplice potrebbe essere una semplice tabella che registra ogni inserimento, aggiornamento o eliminazione dell'istruzione eseguita sul database in un campo di testo con data e campi utente. L'ho fatto una volta su un database Postgres e ha funzionato abbastanza bene per conservare la cronologia)

Answer 4

Creare un tavolo che contiene il nomi delle tabelle che si desidera controllare (es: AuditTable); le colonne minime dovrebbero essere: TableName (varchar), RandomValue (float). Aggiungere un trigger su AuditTable che verrà attivato ogni volta che viene modificato il valore RandomValue: il processo di questo trigger annullerà la creazione dinamica del trigger di controllo per ogni tabella elencata (TableName) in AuditTable. Il trigger di controllo (per ogni tabella) deve essere inserito in una tabella AuditRecord, che cattura: il nome della tabella, l'ID della chiave primaria, il tipo di azione (INSERT/UPDATE/DELETE), i valori dei campi originali e i valori dei campi aggiornati. Se la struttura della tabella cambia, un semplice aggiornamento di RandomValue in AuditTable causerà la rigenerazione dei trigger. Dovrai scrivere il codice che genera automaticamente il trigger per una determinata tabella; si consiglia di utilizzare solo 1 chiave intera primaria su ogni tabella sottoposta a controllo.

Answer 5

Le prestazioni rappresenterebbero un problema per tali audit trail. Vorrei andare per una cache (che è abbastanza fault tolerant) e mantenere il contenuto della cache quando il conteggio raggiunge una determinata soglia (ad esempio 1000 record). Questo sarebbe idealmente un aggiornamento in batch.

Ritengo che anche i database in memoria con opzioni di persistenza (come H2) dovrebbero fare lo stesso. Ma non l'ho usato da solo.

Answer 6

La domanda su come memorizzare i dati dipende da come verrà utilizzata tra altri problemi. Suggerirei di andare con qualcosa di semplice che capisci per ora, testando se hai un'idea del probabile carico che ti aspetti. Quindi, in futuro, apportando miglioramenti se necessario.

In relazione al problema con un sistema di controllo basato sul trigger, dal momento che sembra che tu abbia impostato il lavoro a livello di database, ho un suggerimento. Utilizzare i trigger per registrare le modifiche in una tabella all'interno del database, quindi durante la notte (o comunque frequentemente) elaborare il contenuto della tabella e creare l'audit trail ovunque venga archiviato e svuotare il contenuto della tabella nel database. In questo modo è possibile acquisire le modifiche a livello di database, ma soddisfare comunque i requisiti per archiviare la traccia di controllo attuale altrove.