Con una data/ora, è meglio avere il DB gestirlo o l'applicazione?

Question

Abbiamo in sviluppo la tua app per Java standard e molti dei record che stiamo creando (entità di Hibernate in MySQL) hanno timestamp 'creati' e 'modificati' su di essi.

Ora, io e uno degli sviluppatori non siamo d'accordo - credo che entrambi i campi dovrebbero avere un valore predefinito MySQL di CURRENT_TIMESTAMP, e quindi la modifica può essere modificata dall'app. Vuole sia gestito dall'app.

C'è una ragione convincente per entrambe le decisioni? Non riesco a capire perché vorresti aggiungere passaggi più espliciti al codice, a meno che tu non sia preoccupato per i tuoi server (db, applicazione) che hanno timestamp incoerenti.

Answer 1

• utilizzare DB data/ora se è possibile sacrificare la portabilità. Inoltre, se molto piccole differenze sarebbero importanti per l'applicazione e si avrà più di un server applicazioni/un cluster, è possibile avere problemi con la sincronizzazione dei nodi.
• utilizzare l'applicazione per generare i timestamp nel caso in cui non sia sicuro che il DB prescelto rimanga, oppure se si utilizzano più database, ad esempio MySQL per la produzione, HSQLDB per i test di unità.

Se nessuno di questi argomenti si applicano, utilizzare quello che è più facile per voi (o quello che più gli sviluppatori di votare per)

Se si va per la gestione delle applicazioni, andare per il suggerimento di Pascal Thivent con @PreUpdate , o il vostro campo impostato con un valore predefinito, come:

private Calendar date = Calendar.getInstance(); 

Answer 2

Ha senso allocare tutti i timestamp nello stesso livello per coerenza.

Questo answer a una domanda correlata fornisce un bell'esempio di come farlo in Hibernate.

Answer 3

vorrei gestire questo dal codice e utilizzare Hibernate/dell'APP @PrePersist e @PreUpdate callback:

@PreUpdate 
@PrePersist 
public void setTimeStamps() { 
    modified = new Date(); 
    if (created==null) { 
     created = new Date(); 
    } 
} 

Motivo principale: portabilità (ad es. questo funzionerà con un altro database, ad esempio in un contesto di test, senza alcuna magia di database, senza DEFAULT, senza trigger, niente).

Answer 4

Vorrei utilizzare i trigger e le procedure di archiviazione per mantenere questi campi. Quindi metti la logica nel DB.