Quando una tabella di database dovrebbe usare i timestamp?

Innanzitutto una nota, ho pensato che forse questa domanda appartenesse allo scambio di database, ma penso che sia più ampiamente correlata a una soluzione di programmazione nel suo insieme che ai database. Passerà allo scambio di database se la gente pensa che sia il migliore.

Mi chiedevo quando una tabella del database avrebbe dovuto aggiungere un timestamp creato e aggiornato?

La prima risposta ovvia è che se una logica aziendale deve sapere quando è stato aggiornato qualcosa (come una data di completamento della transazione, ecc.), Deve entrare.

Ma per quanto riguarda i casi di logica non aziendale? Ad esempio, posso pensare a scenari in cui sarebbe davvero utile conoscere l'ora della data in cui le righe sono state modificate per aiutare a individuare i guasti, ad es. Alcune logiche aziendali non riescono e, guardando le righe del database correlate, è possibile identificare che una riga viene aggiornata prima un'altra riga che causa l'errore.

Con questo caso d'uso, sarebbe logico dare a ogni tabella un aggiornamento e creare un timestamp (tranne forse le tabelle enum più banali che non verrebbero aggiornate da nessuna parte dell'applicazione).

Dare ad ogni tabella un timestamp è sicuramente un ottimo modo per impantanare rapidamente un database (anche se potrebbe essere sbagliato).

Quindi, quando una tabella di database dovrebbe creare e aggiornare i timestamp?

Per una migliore e più completa gestione del database e la pratica più saggia è farlo.

In primo luogo, è più probabile che sia uno sviluppatore, vorresti avere traccia delle transazioni e / o attività del database per lo sviluppo e facilitare la traccia di bug ed errori sul tuo codice ogni volta che coinvolge il tuo database.

Inoltre, ogni volta che è necessario tenere traccia delle attività effettuate sul database a fini statistici .

Un altro, capita spesso che forse per il momento non sia necessario tenere traccia delle attività del database, ma è più probabile che lo si farebbe in futuro. Avrà bisogno del tuo tempo oggi, ma ti comprerà di più in futuro .

Come qualcuno che è stato sia bracconiere (sviluppatore) che gamekeeper (DBA), sono sorpreso che molti non vedano ancora il valore in questo e lo considerino gonfio.

In poche parole:

Per qualsiasi tabella in cui vengono aggiunti record (ma mai aggiornati), ad esempio accessi, ecc., Prenderei in considerazione l'aggiunta di una colonna DATE_CREATED.

Per ogni tabella in cui i record vengono aggiunti e aggiornati, prenderei in considerazione l'aggiunta di una colonna DATE_CREATED e una colonna DATE_UPDATED.

Ho lavorato in molti luoghi in cui DATE_CREATED e DATE_UPDATED sono inclusi in ogni tabella per impostazione predefinita come parte del progetto.

Per database più grandi con milioni / miliardi di righe in cui l'aggiornamento del database è stato eseguito nel corso di alcuni giorni, abbiamo anche aggiunto una colonna SOURCE per alcune tabelle che tracciava quale pot di dati causava l'aggiornamento, ad esempio feed di terze parti, aggiornamento utente, modifica DBA, pulizia dei dati ecc.

Nel modo in cui la domanda è formulata, stai chiedendo un elenco di cose. Rischio di non rispondere direttamente alla tua domanda, ma di rispondere quando dovresti usare una soluzione alternativa.

Posso pensare a scenari in cui sarebbe davvero utile conoscere la data e l'ora in cui le righe sono state modificate per aiutare a trovare l'errore

Sarebbe più utile avere un registro di tutti gli aggiornamenti per un dato record? Solo conoscendo l'ultimo aggiornamento, potrebbe non essere sufficiente informazioni. Questo registro potrebbe essere inserito in una tabella separata. Sarebbe più conveniente tenere traccia delle modifiche da più tabelle negli stessi file di registro (non deve essere una tabella). Questo impedisce alcune enormi query di unione di tutte le tabelle change_dates per ottenere aggregati. Ciò trarrebbe vantaggio anche dalla risoluzione dei problemi aiutandoti a vedere una registrazione di più eventi nel tuo sistema.

Inoltre: devi considerare anche gli utenti. Potrebbero non renderlo un caso aziendale, ma quando hai utenti inesperti o quelli in una cultura aziendale in cui non commettono mai un errore utente e vogliono sempre biasimarlo sul computer, qualsiasi tipo di registrazione aiuterà a includere le date di aggiornamento sulle tabelle. In questo caso, potresti voler avere anche un campo Update_UserID.

Una tabella di database dovrebbe includere modelli di creazione e modifica quando si verifica una delle seguenti condizioni:

1. La tabella rappresenta un record principale di alcune attività fornite dall'utente. Se l'utente fa X, e hai sia a Table_Xche a di Table_Ycui sono figli uno-a-molti Table_X, Table_Ynon è un record primario e quindi non ha bisogno dei campi extra.
2. In caso di necessità permanente, temporanea o ricorrente di tracciamento del sistema . Se hai la necessità di verificare che Table_Yvenga aggiornato solo quando Table_Xviene aggiornato, i campi di tracciamento aggiuntivi possono aiutarti.

Nota che nessuno di questi è esclusivo; puoi andare avanti e aggiungerli ovunque per impostazione predefinita e ometterli solo quando necessario per l'ottimizzazione delle prestazioni.

Opinione personale:

Non vedo il valore in una modifiedcolonna.

created, assolutamente, dovrebbe essere aggiunto a ogni tabella del database a meno che non ci sia una giustificazione eccezionale per non farlo. C'è così tanto valore nel farlo lì.

Tuttavia, updatedsembra uno spreco. Perché non limitarti a fare tutto il maiale, crea due tabelle di database, una che specifica un ID documento e un'altra la versione del documento. In un caso molto semplicistico

create table document (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

create table version (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    document_id INT NOT NULL REFERENCES document(id),
    content TEXT NOT NULL,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

Quindi seleziona l'ultimo versiontra quelli documentdesiderati. In questo modo, non solo si salva ogni data di modifica, non solo l'ultima, ma si conserva anche ogni versione di quel documento. L'unico argomento contro di esso è davvero lo spazio sul disco rigido, ma sicuramente quando arrivi al punto in cui sei preoccupato di quale spazio sul disco rigido sta consumando - nella maggior parte dei casi saresti ancora più preoccupato per il controllo delle versioni dei dati