SQL - Progettazione tabella - Colonne DateCreated e DateUpdated

Question

Per la mia applicazione ci sono diverse classi di entità, Utente, Cliente, Posta e così via

Sto per progettare il database e voglio memorizzare la data in cui le entità sono state create e aggiornate. Questo è dove diventa difficile. Sicuramente un'opzione è quella di aggiungere colonne create_timestamp e update_timestamp per ciascuna delle tabelle entità ma che non è così ridondante?

Un'altra possibilità potrebbe essere quella di creare una tabella di registro che memorizzi queste informazioni e che potrebbe essere fatto per contenere tenere traccia degli aggiornamenti per qualsiasi entità.

Qualche pensiero? Mi sto impegnando per implementare quest'ultimo.

Answer 1

L'approccio single-log-table-for-all-tables ha due problemi principali a cui posso pensare:

1. La progettazione della tabella dei log limiterà (probabilmente) la progettazione di tutte le altre tabelle. Molto probabilmente la tabella di registro avrebbe una colonna denominata TableName e quindi un'altra colonna denominata PKValue (che memorizzerebbe il valore della chiave primaria per il record che si sta registrando). Se alcune delle tue tabelle hanno chiavi primarie composte (ad es. Più di una colonna), il design della tua tabella di registro dovrebbe tenerne conto (probabilmente avendo colonne come PKValue1, PKValue2 ecc.).
2. Se si tratta di un'applicazione Web di qualche tipo, l'identità dell'utente che sarebbe disponibile da un trigger sarebbe l'account dell'applicazione, anziché l'ID dell'utente dell'app Web (che è molto probabilmente ciò che si desidera veramente archiviare nel campo CreatedBy). Ciò ti aiuterebbe solo a distinguere tra i record creati dal codice dell'app Web e i record creati diversamente.

Le colonne CreatedDate e ModifiedDate non sono ridondanti solo perché sono definite in ogni tabella. Seguirò questo approccio e metteremo trigger di inserimento e aggiornamento su ogni tabella per popolare quelle colonne. Se avessi anche bisogno di registrare l'utente finale che ha apportato la modifica, salterei i trigger e popolerei i campi timestamp e user dal mio codice dell'applicazione.

Answer 2

Faccio quest'ultimo, con un " log " o " eventi " tavolo. Nella mia esperienza, il "aggiornato" il timestamp diventa frustrante abbastanza rapidamente, perché molte volte ti trovi in ??una correzione in cui non desideri solo l'ultimo aggiornamento.

Answer 3

Con quale frequenza dovrai includere i timestamp creati / aggiornati nel tuo livello di presentazione? Se la risposta è qualcosa di più di "una volta ogni tanto", penso che saresti meglio servito con quelle colonne in ogni tabella.

Answer 4

Su un progetto su cui ho lavorato un paio d'anni fa, abbiamo implementato trigger che hanno aggiornato quella che abbiamo chiamato una tabella di controllo (memorizzava le informazioni di base sulle modifiche apportate, una tabella di controllo per tabella). Ciò includeva la data modificata (e l'ultima modifica).

Sono stati applicati solo alle tabelle chiave (non join o tabelle di dati di riferimento).

Ciò ha rimosso molta della normale frustrazione di dover rendere conto di LastCreated & amp; Campi LastModified, ma ha introdotto il fastidio di mantenere aggiornati i trigger.

Alla fine il design della tabella trigger / audit ha funzionato bene e tutto ciò che dovevamo ricordare era rimuovere e riapplicare i trigger prima di ETL (!).

Answer 5

È per un CMS basato sul web su cui lavoro. La data di creazione e gli ultimi aggiornamenti verranno visualizzati nella maggior parte delle pagine e ci saranno elenchi per le ultime pagine create (e aggiornate). Anche l'interfaccia di amministrazione utilizzerà queste informazioni.