2010-03-28 15 views
19

Probablemente muchos codificadores quieran hacer esta pregunta. es cuáles son las ventajas de cada uno de esos formatos de tiempo MySQL. y cuál preferirás usar en tus aplicaciones.MySQL: ¿Qué es lo mejor para usar, Unix TimeStamp O DATETIME

Para mí utilizo la marca de tiempo de Unix porque tal vez me resulte fácil convertir registros de orden & con ella, y también porque nunca probé lo de DATETIME. pero de todos modos estoy listo para cambiar de opinión si alguien me dice que estoy equivocado.

Gracias

+0

Similar: http://stackoverflow.com/questions/409286/datetime-vs-timestamp –

Respuesta

16

Timestamp (tanto los PHP y los de MySQL) se almacenan utilizando 32 bits (es decir, 4 bytes) números enteros; lo que significa que se limitan a un intervalo de fechas que va de 1970 a 2038.

DATETIME no tienen esa limitación - pero se almacenan utilizando más bytes (8 bytes, si no me equivoco)


Después, entre el almacenamiento de las marcas de tiempo como se ve por PHP, o marcas de tiempo visto por MySQL:


Y, para más información entre TIMESTAMP y DATETIME tipos de datos de MySQL, consulte 10.3.1. The DATETIME, DATE, and TIMESTAMP Types

+3

Están limitados _now_ a 32 bits :) –

+4

¿Quién está utilizando sistemas de 32 bits en 2038? –

+0

'new java.util.Date(). GetTime()' ya es de 64 bits. – osa

1

A menos que la digitalización de los registros antes del 1 de enero de 1970, Me gusta la época UNIX. Es solo cuestión de preferencia, los números enteros sin firmar son más fáciles de manejar cuando se usan múltiples idiomas.

Solo téngalo en cuenta, la época comienza el 1 de enero de 1970. Muchas empresas habían estado en el negocio durante décadas, si no más, antes de eso.

+0

Las marcas de tiempo de Unix, en un entero de 32 bits con signo, pueden almacenar fechas desde 1901, ya que pueden abarcar desde -2147483647 (13 de diciembre de 1901, 8:45:53 p. UTC) hasta 2147483647 (19 de enero de 2038, 3:14:07 a.m. UTC) –

9

Como han dicho otros, las indicaciones de fecha y hora pueden representar un rango menor de fechas (de 1970 a 2038). Sin embargo, las marcas de tiempo miden la cantidad de segundos transcurridos desde Unix Epoch (1970-01-01 00:00:00 UTC), lo que las hace independientes de la zona horaria, mientras que DATETIME almacena una fecha y una hora sin zona horaria. En otras palabras, las marcas de tiempo referencian inequívocamente un punto particular en el tiempo, mientras que el punto exacto en el tiempo al que se refiere DATETIME requiere una zona horaria (que no se almacena en un campo DATETIME). Para ver por qué esto puede importar, considere lo que sucede si cambiamos nuestra zona horaria.

Digamos que queremos almacenar el datetime 2010-03-27 12:00 UTC. Si almacenamos esto y lo recuperamos usando una marca de tiempo o DATETIME, entonces usualmente no parece haber diferencia. Sin embargo, si el servidor ahora cambia para que la zona horaria local sea UTC + 01, entonces obtenemos dos resultados diferentes si sacamos la fecha y hora.

Si hubiéramos configurado el campo a DATETIME, reportaría el datetime como 2010-03-27 12:00, a pesar del cambio en la zona horaria. Si hubiéramos configurado el campo con una marca de tiempo, la fecha sería reportada como 2010-03-27 11:00. Esto no es un problema con ninguno de los tipos de datos, es solo el resultado del hecho de que almacenan información ligeramente diferente.

+0

Las marcas de tiempo de Unix, en un entero de 32 bits con signo, pueden almacenar fechas desde 1901, ya que puede abarcar desde -2147483647 (13 de diciembre de 1901, 8:45:53 PM UTC) a 2147483647 (19 de enero de 2038, 3:14:07 a.m. UTC) –

2

Eso realmente depende.Le daré 2 ejemplos donde uno supera al otro:

La marca de tiempo es mejor que DATETIME cuando desea almacenar la sesión de los usuarios en la base de datos y la hora de creación de la sesión (en formato Timestamp) se usa para recuperar filas rápidamente (con índice).
P. ej. la tabla puede verse así:
[session_create_time AS Timestamp][IP_address AS 32bit Int][etc...]
Tener un índice en las dos primeras columnas realmente puede acelerar sus consultas. Si tenía un tipo de valor DATETIME para el campo session_create_time, podría tomarse mucho más tiempo. Tenga en cuenta que las consultas de sesión se ejecutan cada vez que un usuario solicita una página, por lo que la eficiencia es crucial.

DATETIME es mejor que Timestamp cuando desea almacenar la fecha de nacimiento de un usuario o algunos eventos históricos que requieren un margen de tiempo flexible.

+0

Las marcas de tiempo Unix, en un entero con signo de 32 bits, pueden almacenar fechas hasta 1901, ya que pueden abarcar desde -2147483647 (13 de diciembre). 1901 8:45:53 PM UTC) a 2147483647 (19 de enero de 2038 3:14:07 a.m. UTC). Entonces, a menos que esté almacenando una fecha anterior a 1901, una marca de tiempo funcionaría. –

Cuestiones relacionadas