it-swarm.com.de

Wann sollte eine Datenbanktabelle Zeitstempel verwenden?

Zunächst eine Anmerkung, ich dachte, dass diese Frage vielleicht zum Datenbankaustausch gehört, aber ich denke, dass sie allgemeiner mit einer Programmierlösung als mit Datenbanken zusammenhängt. Wechselt zum Datenbankaustausch, wenn die Leute denken, dass dies der beste ist.

Ich habe mich gefragt, wann in einer Datenbanktabelle ein erstellter und aktualisierter Zeitstempel hinzugefügt werden soll.

Die erste offensichtliche Antwort lautet: Wenn eine Geschäftslogik wissen muss, wann etwas aktualisiert wurde (z. B. ein Abschlussdatum der Transaktion usw.), muss es eingehen.

Aber was ist mit Fällen ohne Geschäftslogik? Zum Beispiel kann ich mir Szenarien vorstellen, in denen es wirklich nützlich wäre, das Datum und die Uhrzeit der Änderung der Zeilen zu kennen, um bei der Fehlersuche zu helfen, z. Einige Geschäftslogiken schlagen fehl, und wenn Sie sich die zugehörigen Datenbankzeilen ansehen, können Sie feststellen, dass eine Zeile vor einer anderen Zeile aktualisiert wird, die den Fehler verursacht.

In diesem Anwendungsfall wäre es sinnvoll, jeder Tabelle ein Update zu geben und einen Zeitstempel zu erstellen (mit Ausnahme der vielleicht trivialsten Aufzählungstabellen, die von keinem Teil der Anwendung aktualisiert würden).

Wenn Sie jeder Tabelle einen Zeitstempel geben, ist dies sicherlich eine gute Möglichkeit, eine Datenbank schnell zu blockieren (obwohl dies falsch sein könnte).

Wann sollte eine Datenbanktabelle Zeitstempel zum Erstellen und Aktualisieren verwenden?

19
Gaz_Edge

Für eine bessere und bessere mfassende Datenbankverwaltung und am klügsten ist es, dies zu tun.

Erstens ist es wahrscheinlicher, dass Sie als Entwickler die Datenbanktransaktionen und/oder -aktivitäten verfolgen möchten, um sie zu entwickeln und Fehler und Fehler in Ihrem Code zu verfolgen, wenn Ihre Datenbank betroffen ist.

Außerdem, wann immer Sie die in Ihrer Datenbank durchgeführten Aktivitäten für statistische Zwecke nachverfolgen müssen.

Zum anderen kommt es häufig vor, dass Sie Ihre Datenbankaktivitäten vorerst nicht nachverfolgen müssen, aber es ist wahrscheinlicher, dass Sie dies in Zukunft tun würden. Es wird deine Zeit heute brauchen, aber es kauft dir in Zukunft mehr.

Als jemand, der sowohl Wilderer (Entwickler) als auch Wildhüter (DBA) war, bin ich überrascht, dass viele den Wert darin immer noch nicht sehen und es für aufgebläht halten.

Einfach gesagt:

Für jede Tabelle, in der Datensätze hinzugefügt (aber nie aktualisiert) werden, z. Anmeldungen usw. Ich würde in Betracht ziehen, eine DATE_CREATED-Spalte hinzuzufügen.

Für jede Tabelle, in der Datensätze hinzugefügt und aktualisiert werden, würde ich in Betracht ziehen, eine DATE_CREATED- und eine DATE_UPDATED-Spalte hinzuzufügen.

Ich habe an vielen Stellen gearbeitet, an denen DATE_CREATED und DATE_UPDATED standardmäßig als Teil des Entwurfs in jeder Tabelle enthalten sind.

Für größere Datenbanken mit Millionen/Milliarden von Zeilen, in denen die Datenbankaktualisierung über einige Tage ausgeführt wurde, haben wir für einige Tabellen eine SOURCE-Spalte hinzugefügt, in der nachverfolgt wird, welcher Datentopf die Aktualisierung verursacht hat, z. Feed von Drittanbietern, Benutzeraktualisierung, DBA-Änderung, Datenbereinigung usw.

16
Robbie Dee

So wie die Frage formuliert ist, fragen Sie nach einer Liste von Dingen. Ich werde das Risiko eingehen, Ihre Frage nicht direkt zu beantworten, sondern zu beantworten, wann Sie eine alternative Lösung verwenden sollten.

Ich kann mir Szenarien vorstellen, in denen es wirklich nützlich wäre, die Datums- und Uhrzeitangaben zu kennen, mit denen Zeilen geändert wurden, um die Fehlersuche zu erleichtern

Wäre es sinnvoller, ein Protokoll aller Aktualisierungen für einen bestimmten Datensatz zu haben? Nur das letzte Update zu kennen, reicht möglicherweise nicht aus. Dieses Protokoll könnte in eine separate Tabelle gestellt werden. Es wäre bequemer, Änderungen von mehreren Tabellen in derselben Protokolldatei (en) zu verfolgen (es muss keine Tabelle sein). Dies verhindert eine massive Vereinigungsabfrage aller Tabellenänderungsdaten, um Aggregate zu erhalten. Dies würde auch der Fehlerbehebung zugute kommen, da Sie mehr Ereignisse in Ihrem System aufzeichnen können.

Zusätzlich: Sie müssen auch die Benutzer berücksichtigen. Sie machen es möglicherweise nicht zu einem Geschäftsfall, aber wenn Sie unerfahrene Benutzer oder Benutzer in einer Unternehmenskultur haben, in denen sie niemals einen Benutzerfehler machen und ihn immer dem Computer vorwerfen möchten, hilft jede Art der Protokollierung, einschließlich Aktualisierungsdaten für Tabellen. In diesem Fall möchten Sie möglicherweise auch ein Update_UserID-Feld haben.

6
JeffO

Eine Datenbanktabelle sollte Erstellungs- und Änderungsvorlagen enthalten, wenn eine der folgenden Bedingungen erfüllt ist:

  1. Die Tabelle repräsentiert ein Primärdatensatz einer vom Benutzer angegebenen Aktivität. Wenn der Benutzer X ausführt und Sie sowohl einen Table_X Als auch einen Table_Y Haben, die eins zu viele Kinder von Table_X Sind, ist Table_Y Kein a Primärdatensatz und benötigt daher keine zusätzlichen Felder.
  2. Wenn Sie einen permanenten, temporären oder wiederkehrenden Bedarf an Systemverfolgung haben. Wenn Sie überprüfen müssen, ob Table_Y Nur aktualisiert wird, wenn Table_X Aktualisiert wird, können die zusätzlichen Verfolgungsfelder hilfreich sein.

Beachten Sie, dass keines davon exklusiv ist. Sie können sie standardmäßig überall hinzufügen und nur dann weglassen, wenn dies für die Leistungsoptimierung erforderlich ist.

1
DougM

Persönliche Meinung:

Ich sehe den Wert nicht in einer modified Spalte.

created sollte unbedingt zu jeder Datenbanktabelle hinzugefügt werden, es sei denn, es gibt eine außergewöhnliche Rechtfertigung, dies nicht zu tun. Es ist so wertvoll, es dort zu haben.

updated scheint jedoch eine Verschwendung zu sein. Warum nicht einfach das ganze Schwein gehen und zwei Datenbanktabellen erstellen, eine mit einer Dokument-ID und eine mit der Dokumentversion. In einem sehr simplen Fall

create table document (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

create table version (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    document_id INT NOT NULL REFERENCES document(id),
    content TEXT NOT NULL,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

Wählen Sie dann das neueste version des gewünschten document aus. Auf diese Weise speichern Sie nicht nur jeden Änderungsdatum - nicht nur das letzte - sondern behalten auch jeden Version dieses Dokuments bei. Das einzige Argument dagegen ist wirklich der Festplattenspeicher, aber sicherlich, wenn Sie an dem Punkt angelangt sind, an dem Sie sich Gedanken darüber machen, welcher Festplattenspeicher belegt ist - in den meisten Fällen wären Sie noch mehr gestört über die Versionierung der Daten

1
Algy Taylor