2010-11-18 14 views
8

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

  1. 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.
  2. Più tabelle come # 1 tranne che senza la colonna della tabella. Ciò separerebbe le modifiche da ciascuna tabella nella propria tabella cronologica.
  3. 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).

+0

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

risposta

5

Le tabelle di controllo vengono colpite molto pesantemente, non si desidera solo una tabella per tutti i controlli o si otterrà il blocco.

Facciamo qualcosa di simile al numero due eccetto che abbiamo due tabelle per tabella (una che memorizza le istanze delle modifiche e una che memorizza i dati effettivi. Ciò semplifica la ricerca di tutti i record memorizzati in una registrazione in una tabella per esempio dal momento che sono tutti inteh stessa istanza.Ciò significa che possiamo facilmente creare script creando nuove tabelle di controllo quando vengono aggiunte nuove tabelle.

Nel caso del secondo, suggerirei di scrivere un proc per ripristinare un record specifico in modo che il ripristino è semplice e non è necessario capirlo ogni volta

+0

HLGEM è un buon punto. Rompere il tutto per motivi di prestazioni ha molto senso e se hai un sacco di lettura/scrittura (milioni al giorno) o grandi aggiornamenti di batch, la soluzione di HLGEM è buona.Tuttavia, se i tuoi bisogni non sono così elevati, l'opzione numero 1 rappresenta un buon compromesso tra prestazioni e manutenzione. I database possono gestire molte cose e sottovalutare l'ottimizzazione può essere un errore a seconda della situazione. – theChrisKent

+0

oh, quindi se un utente aggiorna 5 campi di una riga, una tabella riceve una nuova istanza di una modifica e un'altra tabella riceve 5 nuove righe di aggiornamenti, tutte collegate a quell'istanza? Questo rende il ripristino più facile. –

+0

@Bob Baddeley, si. – HLGEM

0

Vorrei scegliere il numero 1 a mani basse. Il numero 2 sarebbe difficile da mantenere se si decide di aggiungere campi aggiuntivi al proprio monitoraggio e aggiunge molto poco oltre a rimuovere la necessità di una tabella WHERE =? clausola. Il numero 3 è eccessivo. Ecco a cosa servono i backup.

1

Non una risposta, solo ulteriori domande: qual è lo scopo delle tabelle di controllo? Perché le vuoi, hanno bisogno del m, o devono averli? Come saranno usati, a quali domande risponderanno o alle situazioni che affronteranno? Con quale frequenza saranno usati o di rado? Per quanto tempo è necessario mantenere questi dati disponibili e come verranno eliminati o archiviati dopo la data di scadenza?

Le due risposte precedenti [theChrisKen, HLGEM] non sono d'accordo, tuttavia - in base a quello su cui hanno lavorato prima - Scommetto che sono entrambi corretti. Se si contempla come verranno utilizzati e i requisiti di prestazione di tale utilizzo, può aiutare a determinare quale modello è migliore per la propria situazione.

+0

Saranno utilizzati per 1) notifiche di modifiche agli utenti iscritti (su una frequenza istantanea, giornaliera, settimanale o mensile) 2) visualizzazione di una tabella di modifiche a un record accanto al record stesso 3) ripristino di una revisione precedente se le modifiche sono errate o inappropriate. I dati sono parte del record e non vengono mai eliminati. Posso vedere come sia theChrisKen che HLGEM troverebbero le loro soluzioni appropriate in condizioni diverse. Speriamo in una soluzione che si adatti bene, anche se non supererà poche centinaia di utenti (<50 in una volta) o qualche migliaio di righe da tracciare. –

Problemi correlati