Quando una tabella del database dovrebbe utilizzare i timestamp?

Per una migliore e più gestione completa dei database e la pratica più saggia è quella di farlo.

In primo luogo, è più probabile che uno sviluppatore volesse tenere traccia delle transazioni e / o attività del database per lo sviluppo e facilitare l'individuazione di bug ed errori sul codice ogni volta che coinvolge il tuo banca dati.

Inoltre, ogni volta che devi tenere traccia delle attività eseguite sul tuo database per scopi statistici .

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

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

In poche parole:

For any table where records are added (but never updated) e.g. logins etc I'd consider adding a DATE_CREATED column.

For any table where records are added and updated, I'd consider adding a DATE_CREATED and a DATE_UPDATED column.

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

Per database più grandi con milioni / miliardi di righe in cui l'aggiornamento del database ha funzionato nel giro di pochi giorni, abbiamo aggiunto anche una colonna SOURCE per alcune tabelle che monitoravano quale data pot ha causato l'aggiornamento, ad es. Feed di terze parti, aggiornamento utente, modifica DBA, pulizia dati ecc.

Il modo in cui la domanda è formulata, stai chiedendo un elenco di cose. Vado a rischiare non rispondendo direttamente alla tua domanda, ma rispondendo quando dovresti usare una soluzione alternativa.

I can think of scenarios where it would be really useful to know the date time that rows changed to help with fault finding

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

In aggiunta: devi considerare anche gli utenti. Potrebbero non renderlo un caso aziendale, ma quando si hanno utenti inesperti o in una cultura aziendale in cui non fanno mai un errore dell'utente e si vuole sempre dare la colpa al computer, qualsiasi tipo di registrazione aiuterà a includere le date di aggiornamento sulle tabelle. In questo caso, potresti avere anche un campo Update_UserID.

Una tabella di database dovrebbe includere i 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 un Table_X che un Table_Y che sono figli uno-a-molti di Table_X , Table_Y non è un record primario e quindi non ha bisogno dei campi aggiuntivi.
2. In caso di necessità permanenti, temporanee o ricorrenti per il monitoraggio del sistema . Se è necessario verificare che Table_Y venga aggiornato solo quando viene aggiornato Table_X , i campi di monitoraggio aggiuntivi possono essere di aiuto.

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 colonna modified .

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

Tuttavia, updated sembra uno spreco. Perché non limitarti a fare tutto il lavoro, creare due tabelle di database, una che specifica l'ID di un 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'ultima version del document che desideri. In questo modo, non solo si salva ogni data di modifica - non solo l'ultima - ma si mantiene anche la ogni versione di quel documento. L'unico argomento contro di esso è lo spazio su disco rigido, ma sicuramente quando arrivi al punto in cui ti preoccupi di quale spazio su disco stia usando - nella maggior parte dei casi sarai ancora più infastidito sulla versione dei dati