Qual è il migliore tipo di campo da utilizzare per timestamp unix?per timestamp unix
Sarà int(10)
sufficiente per un po '?
Qual è il migliore tipo di campo da utilizzare per timestamp unix?per timestamp unix
Sarà int(10)
sufficiente per un po '?
Per timestamp, è necessario utilizzare il tipo TIMESTAMP
o DATETIME
campo.
non esegue l'aggiornamento della data/ora sql ogni volta che aggiorni/modifichi una riga? – Megaman
Tuttavia, questo ti mette in balia del database e del livello di accesso per i tipi di data e le rappresentazioni di stringa, che possono rendere più difficile la scrittura di applicazioni cross-environment. Spesso è più semplice e più conveniente usare gli interi semplici il cui comportamento è completamente prevedibile, in cui non ci sono altri tipi di data nel database rispetto al quale si spera di confrontare. – bobince
@Megaman: no. Il timestamp è solo un tipo di dati, non ha alcuno di questi comportamenti speciali. – bobince
Unix time_t
o 32 bit di larghezza o 64. Quindi, int(8)
o binary(8)
è sufficiente, almeno per i prossimi 293 miliardi di anni.
La parte migliore di questa risposta è "almeno per i prossimi 293 miliardi di anni". –
Si prega di notare che 'int (8)' non fa sempre ciò che questa risposta suggerisce di fare; [la risposta di Bobince ha una spiegazione.] (http://stackoverflow.com/a/1993585/2014893) –
Lascia che qualcun altro si preoccupi di Y293B –
Il numero in un datatype MySQL INT(n)
non specifica la quantità di spazio di archiviazione riservata, è una larghezza di visualizzazione solo a scopo di formattazione. In quanto tale, INT(10)
corrisponde a un semplice INTEGER
, ovvero un numero con segno a 32 bit.
Quindi questo è sicuramente un tipo di dati appropriato per un timestamp Unix a 32 bit. Ma se vuoi i timestamp a 64 bit non sarà abbastanza; dovresti usare un BIGINT
.
Per il timestamp Unix è possibile utilizzare facilmente INT(4) UNSIGNED
quale valore massimo è 4294967295
. È abbastanza lontano per voi per memorizzare i valori time()
per i prossimi ~ 133 anni. Se la tua app smetterà di funzionare per questo motivo, sarai morto da tempo;)
Puoi anche provare a utilizzare il tipo di dati TIMESTAMP, che è meno problematico e quando vuoi convertirlo in timestamp Unix puoi usare UNIX_TIMESTAMP () funzione.
ex.
SELECT UNIX_TIMESTAMP(col_timestamp) FROM tbl_name;
Che database stai utilizzando? E non useresti un tipo di dati datetime nativo? –