Domanda Dovrei usare il tipo di dati datetime o timestamp in MySQL?


Consiglieresti di usare a appuntamento o a timestamp campo, e perché (usando MySQL)?

Sto lavorando con PHP sul lato server.


2299
2018-01-03 16:14


origine


risposte:


I timestamp in MySQL sono generalmente utilizzati per tenere traccia delle modifiche ai record e vengono spesso aggiornati ogni volta che viene modificato il record. Se si desidera memorizzare un valore specifico, è necessario utilizzare un campo datetime.

Se si intende che si desidera decidere tra l'utilizzo di un timestamp UNIX o un campo datetime MySQL nativo, andare con il formato nativo. Puoi eseguire calcoli all'interno di MySQL in questo modo ("SELECT DATE_ADD(my_datetime, INTERVAL 1 DAY)") ed è semplice cambiare il formato del valore in un timestamp UNIX ("SELECT UNIX_TIMESTAMP(my_datetime)") quando si interroga il record se si vuole operare su di esso con PHP.


1555
2018-01-03 16:26



In MySQL 5 e versioni successive, TIMESTAMP i valori vengono convertiti dal fuso orario corrente a UTC per la memorizzazione e convertiti da UTC al fuso orario corrente per il recupero. (Ciò si verifica solo per il tipo di dati TIMESTAMP e non per altri tipi come DATETIME.)

Per impostazione predefinita, il fuso orario corrente per ciascuna connessione è l'ora del server. Il fuso orario può essere impostato su base per connessione, come descritto in Supporto per il fuso orario di MySQL Server.


814
2018-03-02 11:49



Uso sempre i campi DATETIME per qualcosa di diverso dai metadati di riga (data di creazione o modifica).

Come menzionato nella documentazione di MySQL:

Il tipo DATETIME viene utilizzato quando sono necessari valori che contengono sia informazioni sulla data che sull'ora. MySQL recupera e visualizza i valori DATETIME nel formato 'AAAA-MM-GG HH: MM: SS'. L'intervallo supportato è '1000-01-01 00:00:00' su '9999-12-31 23:59:59'.

...

Il tipo di dati TIMESTAMP ha un intervallo di '1970-01-01 00:00:01' UTC in '2038-01-09 03:14:07' UTC. Ha proprietà variabili, a seconda della versione di MySQL e della modalità SQL in cui viene eseguito il server.

È probabile che tu abbia raggiunto il limite inferiore di TIMESTAMP in uso generale, ad es. memorizzazione della data di nascita.


430
2018-01-04 04:26



Gli esempi seguenti mostrano come TIMESTAMP tipo di data ha cambiato i valori dopo aver cambiato il time-zone to 'america/new_york' dove DATETIMEè invariato.

mysql> show variables like '%time_zone%';
+------------------+---------------------+
| Variable_name    | Value               |
+------------------+---------------------+
| system_time_zone | India Standard Time |
| time_zone        | Asia/Calcutta       |
+------------------+---------------------+

mysql> create table datedemo(
    -> mydatetime datetime,
    -> mytimestamp timestamp
    -> );

mysql> insert into datedemo values ((now()),(now()));

mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime          | mytimestamp         |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 14:11:09 |
+---------------------+---------------------+

mysql> set time_zone="america/new_york";

mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime          | mytimestamp         |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 04:41:09 |
+---------------------+---------------------+

Ho convertito la mia risposta in un articolo in modo che più persone possano trovare ciò utile, MySQL: Datetime Versus Timestamp Tipi di dati.


284
2017-08-21 08:45



La differenza principale è che DATETIME è costante mentre TIMESTAMP è influenzato dal time_zone ambientazione.

Quindi importa solo quando hai - o potrebbe in futuro avere - cluster sincronizzati attraverso fusi orari.

In parole più semplici: Se ho un database in Australia e prendo un dump di quel database per sincronizzare / popolare un database in America, il TIMESTAMP si aggiornerebbe per riflettere il tempo reale dell'evento nel nuovo fuso orario, mentre DATETIME rifletterebbe comunque il tempo dell'evento nel fuso orario au.

Un ottimo esempio di DATETIME utilizzato in cui TIMESTAMP avrebbe dovuto essere utilizzato è in Facebook, dove i loro server non sono mai abbastanza sicuri di quanto tempo è successo attraverso i fusi orari. Una volta stavo avendo una conversazione in cui il tempo diceva che stavo rispondendo ai messaggi prima che il messaggio fosse effettivamente inviato. (Questo, naturalmente, potrebbe anche essere stato causato da una brusca traduzione del fuso orario nel software di messaggistica se gli orari venivano pubblicati piuttosto che sincronizzati).


169
2018-01-14 14:26



Faccio questa decisione su una base semantica.

Io uso un timestamp quando ho bisogno di registrare un (più o meno) punto fisso nel tempo. Ad esempio quando un record è stato inserito nel database o quando è stata eseguita un'azione dell'utente.

Io uso un campo datetime quando la data / ora può essere impostata e cambiata arbitrariamente. Ad esempio quando un utente può salvare successivamente gli appuntamenti di modifica.


109
2018-01-03 17:11



TIMESTAMP è 4 byte Vs 8 byte per DATETIME.

http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html

Ma come ha detto lo scrigno, ha un limite inferiore dell'anno 1970. È fantastico per tutto ciò che potrebbe accadere in futuro;)


86
2018-01-04 09:00



  1. TIMESTAMP è quattro byte contro otto byte per DATETIME.

  2. I timestamp sono anche più chiari sul database e indicizzati più velocemente.

  3. Il tipo DATETIME viene utilizzato quando sono necessari valori che contengono sia informazioni sulla data che sull'ora. MySQL recupera e visualizza i valori DATETIME nel formato 'AAAA-MM-GG HH: MM: SS'. L'intervallo supportato è '1000-01-01 00:00:00' su '9999-12-31 23:59:59'.

Il tipo di dati TIMESTAMP ha un intervallo di '1970-01-01 00:00:01' UTC in '2038-01-09 03:14:07' UTC. Ha proprietà variabili, a seconda della versione di MySQL e della modalità SQL in cui viene eseguito il server.

  1. DATETIME è costante mentre TIMESTAMP viene effettuato dall'impostazione time_zone.

80
2017-12-21 11:12



Raccomando di usare nessuno dei due un campo DATETIME o TIMESTAMP. Se vuoi rappresentare un giorno specifico nel suo insieme (come un compleanno), usa un tipo DATE, ma se sei più specifico di quello, probabilmente sei interessato a registrare un momento reale invece di un'unità di ora (giorno, settimana, mese, anno). Invece di utilizzare DATETIME o TIMESTAMP, utilizzare BIGINT e memorizzare semplicemente il numero di millisecondi dall'epoca (System.currentTimeMillis () se si sta utilizzando Java). Questo ha diversi vantaggi:

  1. Si evita il lock-in del fornitore. Praticamente ogni database supporta gli interi in modo relativamente simile. Supponiamo di voler passare ad un altro database. Vuoi preoccuparti delle differenze tra i valori DATETIME di MySQL e come li definisce Oracle? Anche tra le diverse versioni di MySQL, TIMESTAMPS ha un diverso livello di precisione. Solo di recente MySQL ha supportato i millisecondi nei timestamp.
  2. Nessun problema di fuso orario. Ci sono stati alcuni commenti perspicaci su ciò che accade con i fusi orari con i diversi tipi di dati. Ma è questa conoscenza comune e tutti i tuoi collaboratori prenderanno il tempo per impararlo? D'altra parte, è piuttosto difficile rovinare un BigINT in un java.util.Date. L'utilizzo di un BIGINT causa numerosi problemi con i fusi orari.
  3. Non preoccuparti delle gamme o della precisione. Non devi preoccuparti di ciò che viene interrotto da intervalli di date futuri (TIMESTAMP va solo al 2038).
  4. Integrazione di strumenti di terze parti. Utilizzando un numero intero, è banale per gli strumenti di terze parti (ad esempio EclipseLink) per interfacciarsi con il database. Non tutti gli strumenti di terze parti avranno la stessa comprensione di un "datetime" come fa MySQL. Vuoi provare a capire in Hibernate se dovresti usare un oggetto java.sql.TimeStamp o java.util.Date se stai usando questi tipi di dati personalizzati? L'utilizzo dei tuoi tipi di dati di base rende banale l'utilizzo con strumenti di terze parti.

Questo problema è strettamente correlato a come si dovrebbe memorizzare un valore monetario (ad esempio $ 1,99) in un database. Dovresti usare un decimale, o il tipo di denaro del database, o peggio di tutto un doppio? Tutte e 3 queste opzioni sono terribili, per molti degli stessi motivi sopra elencati. La soluzione consiste nel memorizzare il valore del denaro in centesimi utilizzando BIGINT e quindi convertire i centesimi in dollari quando si visualizza il valore per l'utente. Il lavoro del database è quello di memorizzare i dati e NON di intrepretarli. Tutti questi fantastici tipi di dati che vedi nei database (in particolare Oracle) aggiungono poco e ti mettono in cammino verso il lock-in del fornitore.


74
2018-06-11 23:02



Dipende dall'applicazione, davvero.

Prendi in considerazione la possibilità di impostare un timestamp da un utente a un server a New York, per un appuntamento a Sanghai. Ora quando l'utente si connette a Sanghai, accede allo stesso timestamp dell'appuntamento da un server con mirroring a Tokyo. Vedrà l'appuntamento a Tokyo, a differenza dell'originaria ora di New York.

Quindi per i valori che rappresentano il tempo dell'utente come un appuntamento o una pianificazione, datetime è migliore. Consente all'utente di controllare la data e l'ora desiderate, indipendentemente dalle impostazioni del server. Il tempo impostato è il tempo impostato, non influenzato dal fuso orario del server, dal fuso orario dell'utente o dalle modifiche nel modo in cui viene calcolata l'ora legale (sì, cambia).

D'altra parte, per i valori che rappresentano il tempo di sistema come le transazioni di pagamento, le modifiche alla tabella o la registrazione, utilizzare sempre i timestamp. Il sistema non sarà interessato spostando il server in un altro fuso orario o durante il confronto tra server in fusi orari diversi.

I timestamp sono anche più chiari sul database e indicizzati più velocemente.


37
2017-10-26 21:07