Ha senso standardizzare includendo una data di creazione e un campo di data dell'ultimo aggiornamento su tutte le tabelle DB?

Il mio capo sta attualmente cercando di applicare alcuni standard di sviluppo al nostro team, quindi ieri abbiamo avuto un incontro per discutere degli standard che per lo più stavano andando bene fino a quando non ha sollevato:

• Tutte le tabelle DB avranno una colonna CreatedDate e LastUpdatedDate, aggiornate dai trigger.

A questo punto il nostro team ha subito uno scisma di opinione; la metà di noi pensa che farlo su tutti i tavoli sia una grande mole di lavoro con pochi benefici (lavoriamo su progetti a budget fisso quindi ogni costo deriva dai profitti della nostra azienda); la seconda parte ritiene che aiuterà con il sostegno dei progetti.

Sono fermamente nel vecchio campo. Anche se apprezzo che alcuni casi esterni provocherebbero un miglioramento della sostenibilità delle colonne extra, a mio avviso la quantità di lavoro necessaria per aggiungere le colonne in primo luogo, così come la manutenzione, ci farebbe dedicare meno tempo a più cose importanti come Test di carico o di unità. Inoltre, sono abbastanza sicuro che queste colonne extra renderebbero più imbarazzante l'uso di un ORM, tenendo presente che utilizziamo principalmente C # e Oracle, che all'inizio non sono molto contenti di ORM.

Quindi, la mia domanda è duplice:

• Sono nel campo giusto? Non pretendo di avere competenze di database di fama mondiale, quindi questa potrebbe essere un'aggiunta banalmente facile senza effetti collaterali negativi.
• Come affronteresti una situazione in cui un incontro sugli standard si trasforma in una partita di abbattimento? Come posso davvero vendere che questo standard non ci aiuterà a lungo termine?

Questa è una pratica abbastanza comune, anche se non direi che il supporto sia il vantaggio principale. Il vero vantaggio di questo approccio è mantenere una pista di controllo. È anche comune avere 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 sensibili, sono sicuro che hai sentito parlare di cose come la conformità PCI e SOX . Avere una pista di controllo completa è essenziale per soddisfare tali specifiche.

Dichiarazione di non responsabilità: esistono tuttavia metodi molto migliori per ottenere una traccia di controllo del database> https://stackoverflow.com/questions/1051449/ideas-on-database-design-for-capturing-audit-trails

Il primo argomento non è valido, poiché l'aggiunta di alcuni campi di data e ora gestiti dal database a una serie di tabelle non è un lavoro difficile. Questo è in effetti il ​​tipo di compito che intorpidisce la mente che uno darebbe a uno studente o un tirocinante, e potrebbero facilmente farlo in uno sprint di due settimane con il tempo libero.

Potrebbe anche non essere necessario mappare questi campi nell'ORM, semplicemente perché non si desidera che gli utenti dell'applicazione modifichino questi campi e perché siano utili per la manutenzione e il debug e raramente vengono utilizzati nella logica aziendale. Ho lavorato in negozi che lo facevano in entrambi i modi e sinceramente non ho molta opinione su questo.

I benefici, anche se esagerati, superano di gran lunga qualsiasi costo umano nell'implementazione di tale funzionalità a livello di database, e probabilmente probabilmente inferiore alla potenza cerebrale collettiva dei progetti, grandi menti tecniche che dirottano l'incontro e lo spiegano in un epico incontro travolgente. Quando si calcola l'impatto che alcune riunioni di 1 ora hanno sulla durata di un progetto, probabilmente non si sarà sorpresi dal fatto che siano costose. Immagina i salari orari collettivi e i benefici di tutte quelle persone messe insieme e questo dovrebbe darti un'idea.

... più affermazioni definitive un uomo rende più probabile che si sbagli definitivamente ... - Tyler Durden

questo vale per gli "standard" generali, mentre su alcuni tavoli potrebbe essere una vittoria enorme, su ogni tavolo sarebbe molto probabilmente rumore inutile e più codice da mantenere o dimenticare di mantenere.

c'è un equilibrio da raggiungere 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 la data di aggiornamento . Ci sono molti motivi per cui dovresti inserire una data di creazione e una data di aggiornamento. Per ovvie ragioni che le persone precedenti hanno dichiarato ... che è audit.

Ho progettato sistemi e database per 25 anni e ho lavorato per centinaia di clienti. Non esiste un singolo client che NON ne abbia avuto bisogno.

Ci sono 2 modi base per farlo:

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

2 - L'altra pratica, che preferisco .... sta usando uno strumento di replica per gestirlo. C'è un piccolo sovraccarico e nessun costo per i team DEV. Tuttavia gli strumenti sono costosi. Un ulteriore vantaggio è che il processo di eliminazione può essere verificato molto più facilmente con questo tipo di strumento. Senza uno strumento di replica sarebbe necessario creare una tabella di controllo e trigger di attivazione per le eliminazioni, a mio avviso non è una buona pratica.

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

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

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

Abbiamo la data di creazione e creata da colonne nel nostro database e ci hanno aiutato moltissimo a rintracciare i problemi dei dati. Se dobbiamo ripristinare, ci aiuta a trovare i record corretti nelle tabelle di controllo complete (perché sappiamo dove cercare in una tabella molto grande). Dovrebbe aggiungere anche un creato da e modificato da colonne. Aiuta davvero a sapere chi ha inserito i dati, soprattutto se non si dispone di un controllo completo.

Non riesco a pensare a nessuna applicazione Enterprise che non necessita di controllo in un modo o nell'altro. Apparentemente il tuo capo pensa che abbia bisogno solo di un controllo relativamente delicato. Personalmente preferisco il controllo completo su tutti i database che contengono dati da cui dipende la tua azienda (è molto più semplice ripristinare quei 2000 record non corretti dalle tabelle di controllo piuttosto che ripristinare i backup) e lo richiederei se ci fossero informazioni finanziarie come me ho visto questo tipo di cose aiutare a catturare le persone che commettono frodi. Tutti i controlli devono essere a livello di database.

Come possono aiutare questi dati? Prima di tutto si restringe quando cercare i vecchi dati (in una revisione) e può aiutarti a vedere quale versione del tuo programma era attiva al momento dell'inserimento dei dati. Quindi, se sai di aver risolto il problema nella versione 2.3, che è andato in diretta il 6 luglio 2011 e poi ha riscontrato lo stesso problema con un record inserito il 7 agosto, forse la tua correzione non era buona. Se è necessario ripristinare i vecchi dati, verrà indicato in quale versione dei backup è possibile trovare i vecchi dati se non si dispone di un controllo completo.

Raramente gli sviluppatori sembrano pensare che i dati debbano essere mantenuti nel tempo e che i dati errati debbano essere riparati da qualcuno. Avere cose del genere può essere molto prezioso per quelli di noi che devono fare tali cose. Il tuo capo ha ragione, anche se non credo che sia andata abbastanza avanti nell'auditing. Ci vuole solo un problema davvero serio che è facile da risolvere per giustificare il piccolissimo tempo necessario per aggiungere queste colonne e trigger.

Il carico di lavoro è controverso perché può essere copiato e applicato a tutti i database che tu abbia mai creato. 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 desidera, puoi farti pagare per integrarli nella tua app come meglio crede. A molti piace vedere informazioni aggiuntive su un record come chi lo ha creato / modificato l'ultima volta e quando. Non è necessario inviare a tutti un'e-mail per scoprirlo o mentire. Non è necessario eseguire una query su un registro ogni volta che qualcuno guarda un record.

Metterlo nel database e averlo lì nel caso in cui non sia così difficile e potrebbe consentire di addebitare funzionalità aggiuntive che utilizzano i campi o semplicemente di darvi un feedback su quanti client stanno usando il sistema.

Questo sarebbe piuttosto banale da implementare (forse da 1 a 3 giorni in totale), quindi secondo me è quanto valore aggiungerà alla tua applicazione nel corso della sua vita.

Innanzitutto, sarebbe necessaria un'istruzione alter table per aggiungere le colonne, la tabella alter sarebbe tutta la stessa (tranne il nome della tabella), quindi è possibile scrivere uno script per generare il codice dell'istruzione SQL SQL per tutte le tabelle necessarie . È necessario consentire ai NULL di tenere conto dei dati esistenti e verificare l'esistenza delle colonne in modo che sia nuovamente eseguibile.

In secondo luogo, per le colonne, l'utilizzo di valori predefiniti, come GetUTCDate () (SQL Server, Oracle forse diverso) risolve eventuali aggiunte di codice sull'inserto, quindi la base di codice non deve cambiare per nessuna delle istruzioni di inserimento poiché i valori predefiniti saranno Usato.

Gli aggiornamenti ai dati (modifica all'ultima modifica) potrebbero essere risolti con un trigger di aggiornamento. Ancora una volta, questo trigger sarebbe quasi lo stesso in tutte le tabelle, quindi questo codice trigger (SQL) potrebbe essere generato anche per qualsiasi tabella esistente.

Ci sarebbe potenzialmente un sacco di codice di script sql (a seconda di quante tabelle), ma è un modello ripetibile, quindi potresti generare il codice guardando uno schema DB esistente.