Práctica recomendada para almacenar la fecha en MySQL desde PHP

Question

He estado usando la marca de tiempo Unix toda mi vida.

Me gusta porque es fácil de comparar, es rápido porque lo almaceno como un número entero. Y dado que estoy usando PHP, puedo obtener cualquier formato de fecha/hora con la función date() de unixtimestamp.

Ahora, algunas personas dicen que es mejor usar el formato DATETIME. Pero además del nombre más adecuado, no veo ninguna ventaja.

¿Es realmente mejor utilizar DATETIME, de ser así, cuáles son las ventajas?

Gracias.

Answer 1

Si almacena las fechas como marcas de tiempo Unix en la base de datos, se está haciendo el trabajo pesado. Tienes que convertirlos a los formatos que quieras usar, tienes que hacer los cálculos entre los rangos de fechas, tienes que construir las consultas para obtener datos en un rango. Esto parece contrario a la intuición. ¿Seguramente su "tiempo de programador" se emplea mejor para resolver problemas reales?

Parece una práctica mucho mejor almacenar fechas y horas en el formato adecuado que MySQL tiene disponible, luego use las funciones de la base de datos para crear las consultas para los datos que desea. El tiempo que perdería hacer todas las conversiones y curioseaba es enorme en comparación con la tarde dedicado a la lectura (y comprensión) 11.6 MySQL Date and Time Functions

Answer 2

Una de las ventajas de usar el MySQL date/time types es que puede usar más simplemente el date/time functions in MySQL. El tipo DATE también tiene la ventaja de que solo almacena el día, el mes y el año, por lo que no hay desperdicio de espacio o complicación de comparación que un segundo desde la época del tiempo tendría para situaciones en las que solo se preocupaba por el día y no por el hora.

Personalmente tiendo a utilizar una base de datos como un volcado de datos por lo que estas funciones son de poco interés. En PHP, tiendo a almacenar la fecha en formato entero por casi todos los motivos que usted indica.

Answer 3

Más fácil de comparar, y mysql proporciona muchas funciones de fecha.

Answer 4

El mantenimiento más fácil es un plus. Ver la fecha real cuando lo hace:

select * from table where ... 

es bastante agradable.

Answer 5

El uso de fecha y hora de bases de datos es más eficiente porque cada vez que tenga que mirar que tendría que aplicar FROM_UNIXTIME() función para extraer datos de unix datetime col de la tabla. El uso de esta función en where cláusula ignorará por completo cualquier uso del índice.

dicen que mi pregunta es:

seleccione col1, col2, colUnixdatetime de la tabla donde colUnixdatetime entre wtvdate1 y wtvdate2

que tendría que ejecutar:

SELECT col1, col2, colUnixdatetime de la tabla donde From_Unixtime (colUnixdatetime) entre wtvdate1 y wtvdate2

Esta consulta anterior ignorará por completo cualquier índice, así que no hay uso de índices aquí, ya que nunca se usarán porque siempre tendré que usarlos e una función para obtener la fecha real.

Cualquier función integrada utilizada en LHS de condición en una cláusula where no usaría ningún índice y si tiene una tabla ENORME, su consulta llevará más tiempo.

Answer 6

@Smita V, la consulta ineficiente a la que se refiere es solo así porque está aplicando su función de conversión incorrectamente en cada fila de la tabla, donde debe aplicarla a la condición misma. Por lo tanto, en lugar de

select col1,col2,colUnixdatetime from table where From_Unixtime(colUnixdatetime) between wtvdate1 and wtvdate2 

, que convierte cada fila de la tabla para compararla con la fecha que tiene. Debe usar

select col1,col2,colUnixdatetime from table where colUnixdatetime between UNIX_TIMESTAMP(wtvdate1) and UNIX_TIMESTAMP(wtvdate2). 

Haciéndolo de esta manera, se usarán los índices de tabla apropiados.

@treznik Hace un tiempo pasé de ser un número entero a un tipo de fecha y hora o fecha y hora, por las razones mencionadas anteriormente, en que son mucho más fáciles de leer y manipular (tengo bastante acceso directo a la tabla) Sin embargo últimamente he empezado a volver a pensar en este enfoque por dos razones:

1. no existe una ubicación de zona horaria almacenada, por lo que está inferir la zona horaria en función de su ubicación . Esto puede o no ser un problema para usted.
2. Ignora el horario de verano. Entonces, cuando los relojes vuelvan a las 2 a. M., Obtendrás 1:30 am dos veces, y decir 2011-10-30 01:30 no te deja saber esto, mientras que 1319938200 lo hace. No creo que haya una forma nativa en mysql para almacenar la fecha, incluida la zona horaria, excepto como una cadena (2011-10-30 01:30 BST).

Todavía estoy intentando descubrir la respuesta a esto, yo mismo.

Answer 7

También he sido un gran admirador de la marca de tiempo de Unix toda mi vida. Pero creo que la respuesta correcta es: "depende". Hace poco hice una base de datos de tablas única en la que solo quería enumerar las URL. Habría un campo de fecha, pero el campo de fecha es puramente para ordenar. Es decir, ordenado por last_crawled. Lo que significa que nunca usaré ninguna función de fecha incorporada en ese campo. Es simplemente una manera fácil de obtener primero las entradas más antiguas y nunca aplicaré funciones de fecha a este campo. Ahora, tenía que hice este campo una fecha, habría perdido a cabo en dos cosas:

1. Un campo de fecha y hora es el doble del tamaño de un entero
2. Clasificación por un entero es más rápido (no es 100% seguro de esto, pending outcome of this question)

Sin embargo, para otro sistema tuve que almacenar información transaccional. Esto hizo posible el uso de internal mysql date functions que resultó ser muy útil cuando tuvimos que comenzar a hacer informes.