Ist es besser, wenn die Datenbank von einem Zeitstempel erstellt wird, oder die Anwendung?

8

Wir haben Ihre standardmäßige Java-App in der Entwicklung, und viele der Datensätze, die wir erstellen (Hibernate-Entitäten in MySQL), haben Zeitstempel auf ihnen "erstellt" und "modifiziert".

Nun, ich und einer der Entwickler stimmen nicht zu - ich glaube, dass beide Felder einen MySQL-Standard von CURRENT_TIMESTAMP haben sollten, und dann kann der modifizierte von der App geändert werden. Er möchte beide von der App verwaltet werden.

Gibt es einen zwingenden Grund für beide Entscheidungen? Ich kann nicht verstehen, warum Sie dem Code explizitere Schritte hinzufügen möchten, es sei denn, Sie hatten Bedenken, dass Ihre Server (db, Anwendung) inkonsistente Zeitstempel haben.

    
Jason Maskell 25.01.2010, 07:55
quelle

4 Antworten

7
  • verwenden Sie DB-Zeitstempel, wenn Sie die Portabilität opfern können. Auch wenn sehr kleine Unterschiede für die Anwendung wichtig sind und Sie mehr als einen Anwendungsserver / einen Cluster haben, können Sie Probleme beim Synchronisieren der Knoten haben.
  • Verwenden Sie die Anwendung, um die Zeitstempel zu generieren, falls es nicht sicher ist, dass die ausgewählte Datenbank erhalten bleibt oder wenn Sie mehrere Datenbanken verwenden - zum Beispiel MySQL für die Produktion, HSQLDB für Komponententests.

Wenn keines dieser Argumente zutrifft, verwenden Sie das, das für Sie einfacher ist (oder dasjenige, für das mehr Entwickler wählen)

Wenn Sie sich für die Anwendungsbehandlung entscheiden, gehen Sie entweder zu Pascal Thivents Vorschlag mit @PreUpdate oder lassen Sie Ihr Feld mit einem Standardwert wie:

versehen %Vor%     
Bozho 25.01.2010, 08:10
quelle
3

Es ist sinnvoll, alle Zeitstempel in der gleichen Ebene für Konsistenz zu reservieren.

Diese Antwort zu einer verwandten Frage gibt ein schönes Beispiel, wie man es in Hibernate macht.

    
Robert Christie 25.01.2010 08:03
quelle
3

Ich würde das aus dem Code behandeln und Hibernate / JPAs @PrePersist und @PreUpdate Rückrufe:

%Vor%

Hauptgrund: Portabilität (d. h. dies funktioniert mit einer anderen Datenbank, z. B. in einem Testkontext, ohne Datenbankmagie, keine DEFAULT , kein Trigger, nichts).

    
Pascal Thivent 25.01.2010 08:32
quelle
0

Ich würde Trigger und Speicherprozeduren verwenden, um diese Felder zu verwalten. Also lege die Logik in die DB.

    
chburd 25.01.2010 08:33
quelle

Tags und Links