Perché abbiamo bisogno di colonne di controllo nelle tabelle del database?

Question

Ho visto molti disegni di database che hanno seguito le colonne di audit su tutti i tavoli ...

• Creato da
• Crea DateTime
• Aggiornato da
• Upldated DateTime

Da una prospettiva Vedo le tabelle dalla seguente vista ...

• Entità Tabelle:
  • buon candidato per le colonne di audit)
• Tabelle di riferimento:
  • colonne Audit possono o meno richiesto. In alcuni casi le informazioni dell'ultimo aggiornamento non è affatto necessaria perché il record non è mai sta per essere modificato.)
  Tabelle
• dati di riferimento
  • piace Country nomi, ente statale ecc ... colonne di audit può non richiesti perché queste informazioni vengono create solo durante l'installazione del sistema e non verranno mai modificate.

ho visto molti designer mettono alla cieca tutte le colonne di controllo a tutte le tabelle, è questa pratica buona, se sì, quale potrebbe essere il motivo ...

Voglio solo sapere perché per me sembra illogico. È difficile per me capire perché progettano il loro db in questo modo? Non sto dicendo che hanno torto o ragione, voglio solo sapere il perché?

È possibile anche a me suggerire, se c'è un auditing picchiettio o soluzione alternativa ...

Grazie e saluti

Answer 1

Molte applicazioni sono sviluppate utilizzando un linguaggio OOP in cui v'è generalmente una classe come BusinessObject che contiene informazioni generalmente utili come tali campi di controllo. Non tutte le entità di sottoclassi possono averne bisogno, ma è lì se lo fanno. Poiché il sovraccarico del db è ridotto e le probabilità che il cliente possa richiedere un'altra statistica strana basata sui campi di controllo è meglio averli in giro piuttosto che non averli affatto. Se qualcosa rappresenta un elenco statico di informazioni come i nomi dei paesi, in genere non lo inserirò nel db - il tipo di dati enumerati viene creato solo per tali scopi.

Answer 2

Il controllo dei dati è un controllo interno richiesto per molti sistemi aziendali (per i motivi, vedere Sarbanes Oxley). Deve essere a livello di database per assicurare che tutte le modifiche vengano acquisite in particolare non autorizzate.

Anche con tabelle di ricerca, una modifica non autorizzata potrebbe causare problemi nel sistema e quindi è importante sapere chi ha apportato la modifica e quando.Quando è particolarmente importante perché aiuta il dbas a sapere fino a che punto è possibile recuperare un backup per ripristinare le informazioni accidentalmente o intenzionalmente modificate.

Ci piace pensare che tutti i nostri dipendenti siano affidabili, ma molti dei furti di dati personali e le modifiche dannose per distruggere i dati aziendali provengono da fonti interne (questo è il motivo per cui è pericoloso avere molti dipendenti scontenti) come quasi tutta la frode. Eppure la maggior parte dei programmatori sembra pensare di dover solo proteggere dalle minacce esterne.

Ovviamente ci sono ancora alcune persone che possono apportare modifiche non autorizzate, non è possibile impedire agli amministratori di sistema di farlo. Ma con il controllo almeno puoi limitare il potenziale danno ai dati (e prestare particolare attenzione quando assumi dbas e non concedi nessun altro diritto di amministratore sui tuoi server di database).

Answer 3

Queste colonne sono a beneficio del DBA e degli sviluppatori del database. Forniscono solo un meccanismo rapido per rispondere a domande del tipo "Quando ha fatto questo record l'ultima volta?" "chi l'ha cambiato?" Non sono abbastanza robusti o abbastanza fini per soddisfare la conformità con SOX, HIPAA o altro.

È semplicemente più semplice disporre di queste colonne su ogni tabella. Tutti i dati possono cambiare, quindi è utile sapere quando sono avvenuti cambiamenti, specialmente se non si suppone che i dati cambino. È possibile automatizzare il processo di aggiunta, utilizzando il dizionario dei dati per generare script.

È buona norma che queste colonne vengano compilate indipendentemente dall'applicazione, dai trigger o da un meccanismo simile. Queste colonne sono metadati, l'applicazione non dovrebbe davvero essere a conoscenza di loro.

Affidarsi a un audit trail completo per fornire questa funzionalità di solito non è un'opzione. I dati di audit raccolti per motivi di conformità di solito hanno accesso limitato e possono essere archiviati in una posizione fisica separata.

Answer 4

Mi imbatto per caso in questa discussione, perché la stessa domanda mi è venuta in mente stamattina. Ogni risposta ha il significato e sono assolutamente d'accordo con tutti voi. È innegabile salvaguardare dati aziendali e dati sulle transazioni. Invece di ciò, l'autore si sente dubbioso sui campi di controllo per alcuni dati di configurazione o statici.

Questo tipo di dati di configurazione non sono aggiornabili dagli utenti. Di solito possono essere collocati anche in altri posti, come proprietà, file di configurazione o anche costanti hard-coded. Ovviamente mettere i dati di configurazione in questi luoghi potrebbe essere un cattivo design o uno stile, ma dal punto di vista dell'auditing, hanno importanza? Inoltre, se questi dati sono aggiornabili dagli utenti, gli unici che possono aggiornarli sono dba o hacker. Dba o hacker veramente dannosi conosceranno già le leggi prima di infrangere le leggi e troveranno dei modi per eludere le leggi.

Per me, la domanda è più correlata all'ambiente nella vostra azienda. La tua azienda ha una cultura di tenere traccia di ogni piccola informazione? La tua azienda applica costantemente rigida disciplina, monitoraggio o auditing? Avere questi campi di controllo per i dati non dell'utente sono semplicemente per la loro soddisfazione, più di ogni altro scopo.