Sto costruendo tabelle di controllo per il mio database e devo scegliere quale stile implementare. Attualmente sto considerando tre opzioni, che verranno compilate utilizzando i trigger:struttura tabella di controllo
- Una singola tabella con i campi id | tabella | colonna | riga | old_value | nuovo_valore | timestamp | ID utente. In questo modo, tutte le modifiche verranno registrate in tutte le tabelle in un'unica posizione e si avrà il vantaggio di ridurre al minimo il numero di tabelle. Rende l'interrogazione un po 'difficile, ma non impossibile.
- Più tabelle come # 1 tranne che senza la colonna della tabella. Ciò separerebbe le modifiche da ciascuna tabella nella propria tabella cronologica.
- Più tabelle che rispecchiano lo schema delle tabelle originali da tracciare. Ciò renderebbe i trigger molto più facili da scrivere, renderebbe più semplice il ripristino dei dati se qualcuno volesse ripristinare un record specifico, ma verrebbe a scapito dello storage, poiché ogni campo, anche se non fosse stato modificato, essere duplicato, possibilmente più volte. Inoltre, renderebbe difficile conoscere in modo specifico quali campi sono stati modificati da una versione all'altra.
Ognuna di queste tre opzioni è fattibile, e per quanto posso dire non c'è funzionalità che si offre che è impossibile in un altro. Quindi ci deve essere qualcosa che non sto considerando o un modello che è più standard. Se fa alcuna differenza, questa soluzione deve funzionare sia per mysql che per il server sql (sebbene io possa elaborare le specifiche del codice in un secondo momento).
Implemento una versione del numero 3. In SQL Server, il trigger può identificare ogni colonna che è stata modificata. Lo memorizzo insieme all'intera riga modificata + alcune colonne specifiche di controllo (auditdatetime, userinfo, ecc.). Conservo l'hash, ma creo una vista che decodifica l'hash ed elenca le colonne interessate. – datagod