it-swarm.dev

Ist es sinnvoll zu standardisieren, dass in allen DB-Tabellen ein Erstellungsdatum und ein Feld für das Datum der letzten Aktualisierung enthalten sind?

Meine Chefin versucht derzeit, einige Entwicklungsstandards auf unser Team anzuwenden. Deshalb hatten wir gestern ein Treffen, um die Standards zu besprechen, die größtenteils gut liefen, bis sie sie ansprach:

  • Alle DB-Tabellen verfügen über eine Spalte "CreatedDate" und "LastUpdatedDate", die durch Trigger aktualisiert werden.

Zu diesem Zeitpunkt litt unser Team unter einem Meinungsschisma. Eine Hälfte von uns ist der Meinung, dass dies an allen Tischen eine große Menge an Arbeit mit geringem Nutzen ist (wir arbeiten an Projekten mit festem Budget, sodass alle Kosten aus den Gewinnen unseres Unternehmens stammen). Die zweite Hälfte glaubt, dass es bei der Unterstützung der Projekte helfen wird.

Ich bin fest im ehemaligen Lager. Ich schätze zwar, dass einige externe Fälle dazu führen würden, dass die zusätzlichen Spalten die Unterstützbarkeit verbessern, aber meiner Meinung nach würde der Arbeitsaufwand, der erforderlich wäre, um die Spalten überhaupt hinzuzufügen, sowie die Wartung dazu führen, dass wir weniger Zeit für mehr aufwenden wichtige Dinge wie Unit- oder Load-Testing. Ich bin mir auch ziemlich sicher, dass diese zusätzlichen Spalten die Verwendung eines ORM schwieriger machen würden - wenn man bedenkt, dass wir hauptsächlich C # und Oracle verwenden, was anfangs nicht sehr ORM-glücklich ist.

Meine Frage ist also zweifach:

  • Bin ich im richtigen Lager? Ich behaupte nicht, über weltbekannte Datenbankkenntnisse zu verfügen, daher könnte dies eine trivial einfache Ergänzung ohne nachteilige Nebenwirkungen sein.
  • Wie würden Sie mit einer Situation umgehen, in der ein Treffen über Standards zu einem Schlacken-Match wird? Wie kann ich wirklich verkaufen, dass dieser Standard uns langfristig nicht helfen wird?
39
Ed James

Dies ist eine ziemlich verbreitete Praxis, obwohl ich nicht sagen würde, dass die Unterstützbarkeit der Hauptvorteil ist. Der eigentliche Vorteil dieses Ansatzes besteht darin, einen Prüfpfad zu führen. Es ist auch üblich, eine zusätzliche Spalte mit dem Benutzernamen des Benutzers zu haben, der das letzte Update durchgeführt hat.

Wenn Sie mit finanziellen oder sensiblen Daten zu tun haben, haben Sie bestimmt schon von Dingen wie PCI & SOX Compliance. Ein umfassender Prüfpfad ist für die Erfüllung dieser Spezifikationen unerlässlich.

Haftungsausschluss: Es gibt jedoch viel bessere Möglichkeiten, einen Datenbank-Audit-Trail zu erstellen> https://stackoverflow.com/questions/1051449/ideas-on-database-design-for-capturing-audit-trails

26
MattDavey

Das erstere Argument ist ungültig, da das Hinzufügen einiger datenbankverwalteter Zeitstempelfelder zu einer Reihe von Tabellen keine schwierige Arbeit ist. Dies ist in der Tat die Art von geistesgestörter Aufgabe, die man einem Junior oder einem Praktikanten geben würde, und sie könnten es leicht in einem einzigen zweiwöchigen Sprint mit der Zeit erledigen.

Es kann erforderlich sein, diese Felder in Ihrem ORM zuzuordnen oder nicht, nur weil Sie nicht möchten, dass Anwendungsbenutzer diese Felder ändern, und weil sie für die Wartung und das Debuggen nützlich sind und in der Geschäftslogik nur selten verwendet werden. Ich habe in Geschäften gearbeitet, die es in beide Richtungen gemacht haben, und ich habe ehrlich gesagt keine große Meinung dazu.

Die Vorteile, selbst wenn sie noch übertrieben sind, überwiegen bei weitem die menschlichen Kosten bei der Implementierung solcher Funktionen auf Datenbankebene und sicherlich weniger als die kollektive Gehirnleistung der großen technischen Köpfe, die das Meeting entführen und es in einem epischen Match gegen die Brust ausspielen. Wenn Sie die Auswirkungen einiger einstündiger Besprechungen auf die Lebensdauer eines Projekts zusammenfassen, werden Sie wahrscheinlich nicht überrascht sein, dass sie teuer sind. Stellen Sie sich die kollektiven Stundenlöhne und Sozialleistungen all dieser Menschen zusammen vor, und das sollte Ihnen eine Idee geben.

18
maple_shaft

... je definitiver Aussagen ein Mann macht, desto wahrscheinlicher ist es, dass er definitiv falsch liegt ... - tyler durden

dies gilt für pauschale "Standards", während dies bei einigen Tabellen ein großer Gewinn sein könnte, bei jeder Tabelle wäre es höchstwahrscheinlich nutzloses Rauschen und mehr Code zum Verwalten oder Vergessen zum Verwalten.

hier ist ein Gleichgewicht zu haben, das sollten Sie den Entscheidungsträgern mitteilen.

8
user7519

Ich stimme voll und ganz zu. Fast jede Tabelle in jeder Datenbank sollte mindestens zwei Felder enthalten: Erstellungsdatum und Aktualisierungsdatum. Es gibt viele Gründe, warum Sie ein Erstellungsdatum und ein Aktualisierungsdatum angeben sollten. Aus offensichtlichen Gründen, die von früheren Personen angegeben wurden… was eine Prüfung ist.

Ich entwerfe seit 25 Jahren Systeme und Datenbanken und habe für Hunderte von Kunden gearbeitet. Es gibt keinen einzigen Client, der dies NICHT benötigt.

Es gibt zwei grundlegende Möglichkeiten, dies zu tun:

1 - Die erste Übung besteht darin, die Datenbank die Arbeit erledigen zu lassen und sie direkt in das Tabellen-Design einzufügen. Welches ist das absolute Minimum, würde ich empfehlen.

2 - Die andere Praxis, die ich bevorzuge, ist die Verwendung eines Replikationstools, um dies zu handhaben. DEV-Teams haben wenig Aufwand und keine Kosten. Die Werkzeuge sind jedoch teuer. Ein weiterer Vorteil ist, dass der Löschvorgang mit dieser Art von Tool viel einfacher überwacht werden kann. Ohne ein Replikationstool müssten Sie eine Prüftabelle erstellen und Auslöser für Löschvorgänge auslösen - meiner Meinung nach keine gute Vorgehensweise.

Ein weiterer Vorteil dieser Felder ist das Data Warehouse und der ODS, die IMMER für jedes OLTP - System erstellt wurden. Ohne dieses System können Sie keine inkrementellen Daten effektiv abrufen. Andernfalls besteht die Gefahr, dass Sie die gesamte Datenbank jeden Tag neu laden müssen .

Es gibt eine enorme Anzahl anderer geschäftlicher Gründe für die Eingabe dieser beiden Daten, auf die ich hier nicht näher eingehen werde. Machen Sie Ihre Hausaufgaben und ich bin sicher, dass Sie 3-6-12-48 Monate später sehr froh sein werden, dass Sie diese 2 einfachen Felder eingegeben haben.

Ich habe beide Lösungen implementiert und empfehle sie normalerweise, wo immer dies möglich ist.

8
Andrew Venuto

Wir haben das Erstellungsdatum und die erstellten Spalten in unserer Datenbank und sie haben uns enorm dabei geholfen, Datenprobleme aufzuspüren. Wenn wir zurücksetzen müssen, hilft es uns, die richtigen Datensätze in den vollständigen Audittabellen zu finden (da wir wissen, wo wir in einer sehr großen Tabelle suchen müssen). Sie sollte auch eine von und erstellte Spalte hinzufügen. Es ist wirklich sehr hilfreich zu wissen, in wen die Daten eingegeben wurden, insbesondere wenn Sie keine vollständige Prüfung haben.

Ich kann mir keine Enterprise-Anwendung vorstellen, die keine Prüfung der einen oder anderen Form benötigt. Anscheinend glaubt Ihr Chef, dass es nur einer relativ milden Prüfung bedarf. Persönlich bevorzuge ich die vollständige Prüfung jeder Datenbank, die Daten enthält, von denen Ihr Unternehmen abhängig ist (es ist viel einfacher, diese 2000 fehlerhaften Datensätze aus Prüfungstabellen zurückzusetzen, als Sicherungen wiederherzustellen), und würde sie benötigen, wenn überhaupt finanzielle Informationen vorhanden sind, wie ich Ich habe gesehen, wie solche Dinge dazu beitragen, Betrüger zu fangen. Alle Audits müssen auf Datenbankebene erfolgen.

Wie können diese Daten helfen? Zunächst wird eingegrenzt, wann nach den alten Daten gesucht werden muss (in einer Revision), und es kann Ihnen helfen, festzustellen, welche Version Ihres Programms zum Zeitpunkt der Dateneingabe aktiv war. Wenn Sie also wissen, dass Sie dieses Problem in Version 2.3 behoben haben, die am 6. Juli 2011 online ging, und dann dasselbe Problem mit einem am 7. August eingefügten Datensatz festgestellt haben, war Ihre Korrektur möglicherweise nicht gut. Wenn Sie zu alten Daten zurückkehren müssen, erfahren Sie, in welcher Version der Sicherungen Sie die alten Daten finden können, wenn Sie keine vollständige Überwachung haben.

Entwickler scheinen selten zu glauben, dass Daten im Laufe der Zeit gepflegt werden müssen und dass fehlerhafte Daten von jemandem behoben werden müssen. Solche Dinge zu haben, kann für diejenigen von uns, die solche Dinge tun müssen, sehr wertvoll sein. Ihr Chef hat Recht, obwohl ich nicht glaube, dass sie beim Auditing weit genug gegangen ist. Es ist nur ein wirklich ernstes Problem erforderlich, das leicht zu beheben ist, um die sehr geringe Zeit zu rechtfertigen, die zum Hinzufügen dieser Spalten und Trigger benötigt wird.

5
HLGEM

Die Arbeitslast ist umstritten, da dies per Skript ausgeführt und auf jede Datenbank angewendet werden kann, die Sie jemals erstellen werden. Fügen Sie die Spalten zusammen mit den Triggern zu allen Tabellen hinzu. Sie müssen nur daran denken, es mit Ihrem Build auszuführen.

Soweit der Kunde dies wünscht, können Sie ihn dafür bezahlen lassen, dass er sie nach eigenem Ermessen in Ihre App integriert. Viele möchten zusätzliche Informationen zu einem Datensatz sehen, z. B. wer ihn zuletzt erstellt/geändert hat und wann. Sie müssen nicht jedem eine E-Mail senden, um es herauszufinden oder belogen zu werden. Sie möchten nicht jedes Mal ein Protokoll abfragen müssen, wenn jemand einen Datensatz betrachtet.

Es ist nicht so schwierig, es in die Datenbank zu stellen und dort zu haben, nur für den Fall, dass Sie zusätzliche Funktionen in Rechnung stellen können, die die Felder verwenden, oder Ihnen nur ein Feedback geben können, wie viele Clients das System verwenden.

4
JeffO

Dies wäre ziemlich trivial zu implementieren (vielleicht 1 bis 3 Tage insgesamt). Meiner Meinung nach ist es also, wie viel Wert es Ihrer Anwendung im Laufe ihrer Lebensdauer hinzufügen wird.

Erstens wäre eine alter table-Anweisung erforderlich, um die Spalten hinzuzufügen. Die alter table wäre alle gleich (mit Ausnahme des Tabellennamens), sodass Sie ein Skript schreiben könnten, um die alter SQL-Anweisung für alle benötigten Tabellen zu generieren . MÜSSEN müssen zulassen, dass vorhandene Daten berücksichtigt werden, und prüfen, ob die Spalten vorhanden sind, damit sie erneut ausgeführt werden können.

Zweitens werden für die Spalten unter Verwendung von Standardwerten wie GetUTCDate () (SQL Server, Oracle möglicherweise anders) alle Codierungszusätze beim Einfügen gelöst, sodass sich die Codebasis für keine der Einfügeanweisungen ändern muss, da Standardwerte verwendet werden benutzt.

Die Aktualisierungen von Daten (Änderung zur letzten Änderung) konnten mit einem Aktualisierungsauslöser behoben werden. Auch dieser Trigger wäre für alle Tabellen nahezu gleich, sodass dieser Triggercode (SQL) auch für vorhandene Tabellen generiert werden kann.

Es würde möglicherweise viel SQL-Skriptcode geben (abhängig von der Anzahl der Tabellen), aber es ist ein Muster, das wiederholbar ist, sodass Sie es durch Betrachten eines vorhandenen DB-Schemas generieren können.

1
Jon Raynor