È troppo prolisso per avere sempre timestamp 'modificati' su tutte le entità all'interno di un database?

Prendiamo l'esempio di un importante ERP sul mercato:

• tutti i dati anagrafici e la maggior parte dei dati della transazione contengono 4 campi: l'autore e il timestamp della creazione del record e dell'ultima modifica del record.
• tutte le modifiche critiche del campo (è personalizzabile ciò che è fondamentale) vengono registrate con l'autore della modifica, il timestamp della modifica, il vecchio e il nuovo valore.
I dati
• vengono cancellati solo tramite un processo di archiviazione che tiene traccia della data di archiviazione.

La ragione di ciò non è tecnica, ma è a scopo di controllo. Per i dati finanziari ( SOX ) o in alcuni settori (CGMP ) tale verificabilità è un requisito obbligatorio (a volte legale) .

I primi dati rimangono con i record di dati finché sono nel sistema per comodità. Il secondo registro deve essere in grado di tracciare e spiegare i cambiamenti, ma può essere eliminato periodicamente. A proposito, tutti questi timestamp dei dati correlati possono consentire di identificare le incongruenze che individuano manomissioni non autorizzate.

Dal punto di vista delle prestazioni, le più grandi società del mondo utilizzano tale sistema e i gigabit dei registri sono un requisito che l'architettura hardware e software e il dimensionamento del sistema devono affrontare.

Ovviamente questo approccio è basato su un RDBMS. Se i timestamp e la registrazione fossero disponibili a livello di DB, come per alcuni database NoSQL, sarebbero ridondanti.

Quindi penso che la domanda principale non sia se si tratti di una buona pratica o meno, ma se si tratti di un requisito o meno, e di come possa essere implementata al meglio con gli strumenti disponibili.

would it be a 'bad idea', to implement a policy/practice to always persist data and to always implement 'auto-updating' (if possible) created, updated and deleted properties?

Persistenza e auditabilità (non dichiarate ma implicite) sono obiettivi preziosi, ed è bene pensare in questa direzione per i casi in cui ne avete bisogno. Detto questo, per rispondere alle tue domande:

Sì . Sarebbe una cattiva idea implementare questi campi come criterio su tutte le tabelle. Non a causa dello spazio necessario, ma perché questa implementazione manca il segno sulla persistenza e il livello a cui si verificano gli audit.

La persistenza non riguarda solo la rimozione (disattivazione) anziché la cancellazione. Probabilmente il tuo # 1 modo di perdere dati è attraverso gli aggiornamenti. Ogni volta che alcuni valori vengono aggiornati, (nella maggior parte dei database) i vecchi valori vengono persi e insieme a loro ogni intuizione che essi contengono. Con solo timestamp, non puoi rispondere a domande più commoventi come: chi ha apportato questa modifica? Cosa hanno cambiato? e perché? Inoltre, la persistenza completa, inclusi gli aggiornamenti, può solo rispondere alla domanda intermedia e suggerire quest'ultima.

Rispondere agli altri due deve mirare più in alto della semplice tecnologia del database usata ... più alta delle operazioni CRUD. A CreatedOn (o created_on se preferisci) la data / ora potrebbe dirti quando è stata eseguita una INSERT sulla tabella. Ma il tuo capo non è propenso a fare quella domanda. Potrebbe chiedere: è quell'ordine una conversione di quota da un venditore? O è un ordine web? O è un ordine di spedizione drop da un partner? created_on non avrà questa risposta. Quando il tuo capo ti chiede se l'ordine è stato spedito, il francobollo updated_on della tabella di spedizione non è la risposta giusta (forse le informazioni di spedizione sono state modificate?). Ecco perché i timestamp di CRUD sono spesso (non sempre) il livello sbagliato di verificabilità. "Quando" è una domanda importante alla quale si risponde con timestamp, ma solo se è collegata a un caso di utilizzo aziendale. Nello scenario di spedizione, un campo shipped_on potrebbe essere la risposta perfetta, perché risponde a una domanda aziendale, mentre updated_on risponde solo a una tecnica.

Sembra che tu stia viaggiando in modo approssimativo un tipo di pattern Event Sourcing , che è pienamente persistente e verificabile. Come parte del viaggio, devi capire che i concetti importanti per te come sviluppatore (ad esempio le operazioni CRUD) non sono direttamente correlati ai concetti di business. L'unico modo per assicurarsi di registrare le informazioni necessarie per rispondere alle domande giuste è parlare con le parti interessate e conoscere lo spazio problema da loro.

L'implementazione di timestamp CRUD su All The Things come politica è nel migliore dei casi lo spazio sprecato (avendo risposte alle domande che nessuno ti pone), e nel peggiore sarà una distrazione per rispondere a domande di vitale importanza (dando una risposta a una domanda diversa da quella richiesta).

P.S. Uso timbri come CreatedOn a volte. Non c'è niente di sbagliato in questo. Assicurati solo che rispondano a domande utili.

P.P.S. Se questa domanda fosse su dba.stackexchange.com , allora potrei rispondere in modo diverso in base ai meriti tecnici di tale approccio. Ma credo che questo punto di vista del progetto / architettura del sistema risponda meglio alla domanda per questo sito.

No, non è troppo prolisso. Direi che è quasi una buona pratica.

Avere creato e modificato le date su una base per record consente di vedere quanto vecchia sia quella particolare riga di dati. La maggior parte dei sistemi che ho incontrato hanno requisiti di conservazione dei dati. Avendo queste date, si può avere un processo di eliminazione dei dati per mantenere solo una certa quantità di dati in una finestra di tempo scorrevole. Ciò consente di risparmiare spazio di archiviazione (denaro) e mantiene l'applicazione fuori controllo senza problemi di prestazioni. Qualsiasi applicazione dovrebbe sempre avere i requisiti su quanto tempo è necessario conservare i dati transazionali. Se potrebbe essere di alcuni mesi o anni, ma in ogni caso, avere questi indicatori di dati può semplificare la manutenzione dei dati e consentire una corretta capacità di archiviazione dei dati e pianificazione.

Inoltre, può rispondere a domande aziendali come:

Quanti dati sono stati aggiunti nel mese scorso? Quanti aggiornamenti si sono verificati nelle ultime 24 ore?

Quindi avere questi indicatori di dati può aiutare anche con queste query.

Penso che molte applicazioni dovrebbero averli. Questi valori sono più utili per la risoluzione dei problemi e altre esigenze di supporto. Anche le eliminazioni software hanno vantaggi, ma è sempre necessario includerle nella logica della query. Solo perché puoi usarli, non sono abbastanza. Molte esigenze di auditing richiedono più dati e sofisticazione, anche al di là del logging.

Le agenzie di regolamentazione possono richiedere che l'auditing mostri una storia di tutte le possibilità. La tua domanda potrebbe anche essere richiesta per mostrare cosa è stato cambiato, da chi e quando. Questa è una buona ragione per fare attenzione a quanti campi inserisci in una singola tabella.

Attenzione: i dati e la larghezza di banda possono essere economici, ma ci sono problemi di prestazioni. Scoprirai che molte installazioni hanno un humungous hardware dedicato al database. Questo perché una volta che lo fai crescere e inizi a considerare un cluster, diventa complicato e costoso.

C'è di più in YAGNI. Potresti averne bisogno, ma ora non sai se ne hai ancora bisogno per cui sei bloccato. YMHNIBNYDKIYSNISYSWI. Questo è molto peggio. Ci dovrebbe sempre essere una ragione per qualcosa. Penso che aiutare a risolvere i problemi sia sufficiente, ma se trovi che non ne hai davvero bisogno; sbarazzarsi di esso o non inserirlo affatto.