Data vs millisecondi | per scalablility, il risparmio, la ricerca e l'ottenimento di tempo in Java + MySQL (o altro Db di)

Question

che è il più vantaggioso in Java e un DB per DateTime? (Usando JodaTime come data)

(oggetto DateTime (Java) + TIMESTAMP (DB)) lungo VS (millisecondi (Java) + BIGINT (DB)

per l'utilizzo delle informazioni DateTime in un'applicazione Web Java supportato da un database sottostante

Aree di interesse

• manipolazione, trasformazione e utilizzo della memoria in Java
• risparmio utilizzando lo spazio di archiviazione efficiente un database MySQL
• facilità di porting una colonna BIGINT / TIMESTAMP per altri DB
• facilità di ricerca del DB per un BIGINT / timestamp o tra due BIGINTs / timestamp

es. Dire che ho avuto un evento con un inizio e di fine DateTime. E 'più veloce per cercare gli eventi in date utilizzando BIGINT nel DB di TIMESTAMP

Potrei scambiare il DB sottostante emergano problemi di scalabilità e recupero.

Sarebbe salvare il DateTime come timestamp in un DB MySQL problemi di piombo quando il porting a un altro DB come Oracle?

---

Attualmente uso il Joda DateTime in Java quindi memorizzando millisecondo di quel valore.

Quando si recuperano esso, posso convertire i millisecondi di nuovo ad un oggetto DateTime e lo mostro.

Answer 1

Ci sono due domande qui. In primo luogo, ciò che l'astrazione si dovrebbe utilizzare in Java per rappresentare il tempo? Joda Il tempo è sicuramente meglio di java.util.Date. Se vi state chiedendo se usare semplicemente un lungo - immagino non si può farla franca che se avete bisogno di fare alcuna manipolazione data o paragone. Così, Joda Time.

E allora è sicuramente meglio usare timestamp per questo in MySQL in quanto sarà quasi identica stoccaggio-saggio e MySQL tratterà il valore in modo appropriato, come una data, quando si desidera utilizzare le funzioni di data sulla colonna. driver JDBC sarà anche capire che dovrebbe essere associato a un tipo di data.

Non riesco a immaginare avrete difficoltà porting di un tipo di data, rappresentato correttamente come una data nello schema, in un altro database, nel caso fosse necessario. Posso immaginare i problemi se si trattano il tipo di data come un bigint, che è meno corretto.

Quindi, è sufficiente scegliere i tipi più corretti qui. Dubito che ci sia qualsiasi vincita prestazioni disponibili dalla scelta di un tipo meno adatto in ogni caso.

Answer 2

Sono sempre utilizzando l'approccio “millisecondi dal 1970”. In questo modo non devo preoccuparsi di quale fuso orario la data appartiene perché la data del database è sempre UTC.

Answer 3

Ovviamente dipende da cosa si vuole fare con i dati, ma mi consiglia di utilizzare il tipo nativo del DB per ora / data (qualunque esso sia) per la memorizzazione nel DB. Questo è lo standard per i database, e la maggior parte delle funzioni data / ora in DB si aspettano i dati in quella forma.

Nota speciale su MySQL:

Sebbene sia possibile utilizzare timestamp per valori di data / ora, essere consapevoli che TIMESTAMP non può registrare le date precedenti al 1970-01-01. Così, mentre è ok per le date nei pressi di "ora" (come ad esempio le date di creazione / modifica), non è appropriat per date possibilmente storici come la data di nascita. Quindi utilizzare solo TIMESTAMP se si è completamente certi che mai bisogno di date storiche.