Ha senso standardizzare tra cui una data di creazione e l'ultimo campo della data di aggiornamento su tutte le tabelle DB?

Questa è una pratica abbastanza comune, anche se non direi che la supportabilità è il principale vantaggio. Il vero vantaggio di questo approccio è mantenere una pista di controllo. È anche comune disporre di una colonna aggiuntiva contenente il nome utente dell'utente che ha effettuato l'ultimo aggiornamento.

Se hai a che fare con qualsiasi tipo di dati finanziari o sensoriali, sono sicuro che hai sentito di cose come PCI & SOX conformità. Avere una pista di controllo completa è essenziale per soddisfare tali specifiche ..

Dichiarazione di non responsabilità: esistono tuttavia modi molto migliori per ottenere un audit trail del database > link

L'argomento precedente non è valido, perché l'aggiunta di pochi campi di timestamp gestiti da database su una serie di tabelle non è un lavoro difficile. Questo è in realtà il tipo di lavoro che ti dà la mente di uno junior o di un tirocinante, e potrebbero farlo facilmente in uno sprint di sole due settimane con un po 'di tempo libero.

Potrebbe non essere necessario mappare questi campi nel tuo ORM, semplicemente perché non vuoi che gli utenti delle applicazioni modifichino questi campi e perché sono utili per la manutenzione e il debug e raramente sono utilizzati nella logica di business. Ho lavorato in negozi che lo hanno fatto in entrambi i modi e francamente non ho molta opinione in merito.

I benefici, anche se esagerati, superano di gran lunga i costi umani nell'implementazione di tale funzionalità a livello di database, e probabilmente probabilmente meno del potere collettivo del cervello dei progetti, grandi menti tecniche che dirottano l'incontro e lo sparano in una cassa epica fiammifero Quando prendi parte all'impatto che alcune riunioni di 1 ora hanno sulla durata di un progetto, probabilmente non sarai sorpreso dal fatto che siano costose. Immagina i salari orari e i benefici collettivi di tutte queste persone combinate e questo dovrebbe darti un'idea.

... the more definitive statements a man makes the more likely he is to be definitively wrong ... - tyler durden

questo si applica agli "standard" generali, mentre su alcuni tavoli questa potrebbe essere una grande vittoria, sulla tabella ogni sarebbe molto probabilmente un rumore inutile e più codice da mantenere o dimenticare da mantenere.

c'è un equilibrio da avere qui, questo è ciò che dovresti spingere ai decisori.

Sono d'accordo con tutto il cuore. Quasi ogni tabella in ogni database dovrebbe avere almeno 2 campi: la data di creazione e data di aggiornamento . Ci sono molti motivi per cui devi inserire una data di creazione e una data di aggiornamento. Per ovvi motivi che le persone precedenti hanno dichiarato ... che è l'audit.

Ho progettato sistemi e database per 25 anni e ho lavorato per centinaia di clienti. Non c'è un singolo cliente che NON ha bisogno di questo.

Ci sono 2 modi di base per farlo:

1 - La prima pratica è lasciare che il database faccia il lavoro e inserirlo direttamente nella progettazione della tabella. Qual è il minimo indispensabile, lo consiglierei.

2 - L'altra pratica, che preferisco .... sta usando uno strumento di replica per gestire questo. C'è poco overhead e nessun costo per i team DEV. Tuttavia gli strumenti sono costosi. Un ulteriore vantaggio è che il processo di cancellazione può essere controllato molto più facilmente con questo tipo di strumento. Senza uno strumento di replica, sarebbe necessario creare una tabella di controllo e attivare i trigger per le eliminazioni, non una buona pratica secondo me.

Un altro vantaggio di avere questi campi è il data warehouse e ODS che è SEMPRE costruito per qualsiasi sistema OLTP. Non è possibile estrarre efficacemente i dati incrementali senza di essi. Altrimenti rischi di dover ricaricare l'intero DB ogni giorno.

C'è un enorme numero di altri motivi commerciali per inserire queste 2 date, che non approfondirò qui. Fai i compiti e sono sicuro che tra 3-6 e 12-48 mesi sarai felice di aver inserito questi due semplici campi.

Ho implementato e di solito raccomando entrambe le soluzioni, ove possibile.

Il carico di lavoro è discutibile perché può essere copiato e applicato a tutti i database che creerai. Aggiungi le colonne a tutte le tabelle insieme ai trigger. Devi solo ricordarti di eseguirlo con la tua build.

Per quanto riguarda ciò che il cliente vuole, puoi farti pagare per integrarli nella tua app come meglio credono. A molti piace vedere ulteriori informazioni su un disco come chi l'ha creato / cambiato e quando e quando. Non c'è bisogno di inviare a tutti una mail per scoprire o essere mentito. Non vuoi dover interrogare un log ogni volta che qualcuno guarda un record.

Inserirlo nel database e averlo lì solo nel caso non sia così difficile e potrebbe consentire di addebitare ulteriori funzionalità che utilizzano i campi o solo per fornire un feedback su quanto i client utilizzano il sistema.

Abbiamo la data creata e creata da colonne nel nostro database e ci hanno aiutato moltissimo a rintracciare i problemi relativi ai dati. Se abbiamo bisogno di ripristinare, ci aiuta a trovare i record corretti nelle tabelle di controllo complete (perché sappiamo dove cercare in una tabella molto grande). Dovrebbe aggiungere un creato e modificato anche da colonne. È davvero utile sapere chi inserisce i dati in particolare se non si ha il controllo completo.

Non riesco a pensare a nessuna applicazione Enterprise che non abbia bisogno di auditing di qualche tipo. A quanto pare il tuo capo pensa che abbia bisogno solo di un audit relativamente mite. Personalmente privilegio il controllo completo su tutti i database che contengono dati dipendenti dalla tua azienda (è molto più semplice ripristinare quei 2000 record non validi dalle tabelle di controllo che ripristinare i backup) e richiederei se ci sono informazioni finanziarie come Ho visto questo tipo di cose aiutare a catturare persone che commettono frodi. Tutto il controllo deve essere a livello di database.

Come possono aiutare questi dati? Beh, prima si restringe quando cercare i vecchi dati (in una revisione) e può aiutarti a vedere quale versione del tuo programma era attiva nel momento in cui i dati sono stati inseriti. Quindi, se sai che hai risolto il problema nella versione 2.3 che è stata pubblicata il 6 luglio 2011 e poi hai riscontrato lo stesso problema con un record inserito il 7 agosto, allora forse la tua correzione non andava bene. Se hai bisogno di ripristinare i vecchi dati ti dirà quale versione dei backup puoi trovare i vecchi dati se non hai il pieno controllo.

Gli sviluppatori raramente sembrano pensare che i dati debbano essere mantenuti nel tempo e che i dati cattivi devono essere aggiustati da qualcuno. Avere cose del genere può essere molto prezioso per quelli di noi che devono fare queste cose. Il tuo capo ha ragione, anche se non penso che sia andata abbastanza lontano nell'auditing. Ci vuole solo un problema veramente serio che è facile da correggere per giustificare la quantità di tempo che ci vorrà per aggiungere queste colonne e trigger.

Sarebbe una cosa abbastanza semplice da implementare (forse da 1 a 3 giorni in totale), quindi a mio avviso è il valore che aggiungerà alla tua applicazione nel corso della sua vita.

In primo luogo, sarebbe necessaria un'istruzione alter table per aggiungere le colonne, la tabella delle alterazioni sarebbe sempre la stessa (eccetto per il nome della tabella), quindi potresti scrivere uno script per codice generare l'alter istruzione SQL per tutte le tabelle questo è necessario. È necessario consentire ai NULL di tenere conto dei dati esistenti e verificare l'esistenza delle colonne in modo che possano essere riproducibili.

In secondo luogo, per le colonne, l'utilizzo di valori predefiniti, come GetUTCDate () (SQL Server, Oracle forse diverso) risolve eventuali aggiunte di codifica sull'inserto, quindi il codice base non deve essere modificato per nessuna delle istruzioni di inserimento dal valore predefinito i valori saranno usati.

Gli aggiornamenti ai dati (modifica dell'ultima modifica) potrebbero essere risolti con un trigger di aggiornamento. Ancora una volta, questo trigger sarebbe pressoché uguale su tutte le tabelle, quindi questo codice trigger (SQL) potrebbe essere generato dal codice anche per le tabelle esistenti.

Ci sarebbe potenzialmente un sacco di codice script sql (a seconda di quante tabelle), ma è un pattern ripetibile, quindi potresti codificarlo generando uno schema DB esistente.