SQL - Tabellenentwurf - DateCreated und DateUpdated Spalten

Question

Für meine Anwendung gibt es mehrere Entitätsklassen, User, Customer, Post, und so weiter

Ich bin dabei, die Datenbank zu entwerfen, und ich möchte das Datum speichern, an dem die Entitäten erstellt und aktualisiert wurden. An dieser Stelle wird es knifflig. Sicherlich ist eine Möglichkeit, created_timestamp und update_timestamp Spalten für jede der Entitätstabellen hinzuzufügen, aber ist das nicht zu aufwändig?

Eine andere Möglichkeit wäre, eine Protokolltabelle zu erstellen, die diese Informationen speichert, und sie könnte so gestaltet werden, dass sie die Aktualisierungen für 何れも Einheit.

Haben Sie eine Idee? Ich neige dazu, Letzteres zu implementieren.

Answer 1

Der Ansatz "eine Protokolltabelle für alle Tabellen" hat zwei Hauptprobleme, die mir einfallen:

1. Das Design der Protokolltabelle wird (wahrscheinlich) das Design aller anderen Tabellen einschränken. Höchstwahrscheinlich wird die Protokolltabelle eine Spalte mit dem Namen Tabellenname und eine weitere Spalte mit dem Namen PKValue haben (in der der Primärschlüsselwert für den zu protokollierenden Datensatz gespeichert wird). Wenn einige Ihrer Tabellen zusammengesetzte Primärschlüssel haben (d.h. mehr als eine Spalte), dann müsste der Entwurf Ihrer Protokolltabelle dies berücksichtigen (wahrscheinlich durch Spalten wie PKValue1, PKValue2 usw.).
2. Wenn es sich um eine Webanwendung handelt, wäre die über einen Auslöser verfügbare Benutzeridentität das Konto der Anwendung und nicht die ID des Webanwendungsbenutzers (die Sie höchstwahrscheinlich in Ihrem Feld CreatedBy speichern möchten). Dies würde Ihnen nur helfen, zwischen Datensätzen zu unterscheiden, die durch Ihren Webanwendungscode erstellt wurden, und solchen, die auf andere Weise erstellt wurden.

Die Spalten CreatedDate und ModifiedDate sind nicht redundant, nur weil sie in jeder Tabelle definiert sind. Ich würde bei diesem Ansatz bleiben und für jede Tabelle Einfüge- und Aktualisierungs-Trigger einrichten, um diese Spalten zu füllen. Wenn ich auch den Endbenutzer aufzeichnen müsste, der die Änderung vorgenommen hat, würde ich die Trigger weglassen und die Felder "Zeitstempel" und "Benutzer" über meinen Anwendungscode auffüllen.

Answer 2

Ich verwende letzteres, mit einer Tabelle "Log" oder "Events". Meiner Erfahrung nach wird der "Aktualisierungs"-Zeitstempel ziemlich schnell frustrierend, weil man sich oft in einer Situation wiederfindet, in der man nicht nur die allerletzte Aktualisierungszeit haben möchte.

Answer 3

Wie oft müssen Sie die erstellten/aktualisierten Zeitstempel in Ihre Präsentationsebene aufnehmen? Wenn die Antwort auf diese Frage mehr als "einmal in einer ganzen Weile" lautet, wäre es meiner Meinung nach besser, wenn Sie diese Spalten in jeder Tabelle hätten.

Answer 4

Bei einem Projekt, an dem ich vor einigen Jahren gearbeitet habe, haben wir Trigger implementiert, die eine so genannte Audit-Tabelle aktualisierten (sie speicherte grundlegende Informationen über die vorgenommenen Änderungen, eine Audit-Tabelle pro Tabelle). Dazu gehörte das Änderungsdatum (und die letzte Änderung).

Sie wurden nur auf Schlüsseltabellen angewendet (nicht auf Joins oder Referenzdatentabellen).

Dadurch wurde ein großer Teil der Frustration beseitigt, die mit der Berücksichtigung der Felder LastCreated und LastModified verbunden ist, aber es wurde das Ärgernis eingeführt, die Auslöser auf dem neuesten Stand zu halten.

Am Ende funktionierte der Entwurf der Trigger-/Audit-Tabellen gut, und wir mussten nur daran denken, die Trigger vor der ETL(!) zu entfernen und erneut anzuwenden.

Answer 5

Es ist für ein webbasiertes CMS, an dem ich arbeite. Das Erstellungs- und das letzte Aktualisierungsdatum werden auf den meisten Seiten angezeigt und es wird Listen für die zuletzt erstellten (und aktualisierten) Seiten geben. Die Verwaltungsschnittstelle wird diese Informationen ebenfalls verwenden.