¿Debo utilizar un número entero grande o un número entero regular en MySQL para almacenar una marca de tiempo? Planeo almacenarlo en una INT y no en la marca de tiempo o en la fecha, entonces ¿qué tipo de INT debo usar?¿Debo usar una INT grande o una INT regular en MySQL para almacenar una marca de tiempo?
Int diera la vuelta a un negativo en 2038 (si usa la marca de tiempo UNIX): http://en.wikipedia.org/wiki/2038_problem.
por lo BIGINT es probablemente la opción más segura
No habrá un problema y2k38 más de lo que hubo un problema y2k. En algún momento alrededor de 2030, habrá una loca carrera para cambiar todas las bases de datos y usar sellos de 64 bits, y esto será fácil, al menos para las personas que usaron inteligentemente la marca de tiempo en las tablas en lugar de números enteros :-) – paxdiablo
* encogimiento de hombros * .... si quieres convertirlo en unsigned int, puedes subir bastante al 2100 y algo más (siempre que tengas una función que siga entregando los números, y los conviertas) –
Bueno. Hay personas inteligentes que usan bigint para trabajar con datases (las bases de datos son bases de datos, no bases de datos + programas para marketing) debido a la portabilidad y problemas con formatos de fecha y hora con bases de datos o versiones de bases de datos. Int son Int. y no problema con Oracle, SQL, MySQL, MariaDb y otros. Datatimes tipos, demasiados problemas en la búsqueda de Google con varias actualizaciones de bases de datos, conpatibilties .. Mucha veces no es cuestión de inteligencia, es cuestion de experiencia ;-) Muchas veces no es una cuestión de inteligencia, es una cuestión de experiencia ;-) – abkrim
Debe almacenarlo en una marca de tiempo ya que es muy probable que lo que el DBMS optimizará para los datos de marca de tiempo.
Tengo curiosidad por saber por qué sacrificaría todo el trabajo duro que los desarrolladores de MySQL han puesto para hacer que las marcas de tiempo funcionen como deberían y para reemplazarlo con algo que seguramente no funcionará tan bien.
Puesto que usted no indica qué desea utilizar un número entero, que sólo voy a asumir que era una locura temporal y que pronto se recupere :-)
. Generalmente se usan porque php y otros idiomas similares facilitan mucho el trabajo con marcas de tiempo que con un formato de fecha sql adecuado. –
En ese caso, usaría UNIX_TIMESTAMP() para obtener el time_t subyacente que es lo que hay en el DB de todos modos. – paxdiablo
En mi situación, simplemente funciona, las versiones más nuevas en mysql almacenan datetime e timestamp en este formato now 0000-00-00 en lugar de 0000000 (los números y guiones pueden estar apagados pero se entiende la idea. Timestamp solía ser una marca de tiempo REAL) pero ya no más. Todas las funciones de mi tiempo necesitan una marca de tiempo real de mysql, así que si almaceno una marca de tiempo en un INT, usa menos espacio y es menos procesamiento/conversión de un lado a otro.Como un dicho, toda mi función necesita una marca de tiempo, así que si le doy la marca de tiempo de estilo más nueva, entonces necesito convertirla en una marca de tiempo real en php. Después de varios días de probar – JasonDavis
Creo que depende totalmente de lo que quiere hacer. Hay unos pocos tipos adecuados para los tipos de hora/fecha (véase: http://dev.mysql.com/doc/refman/5.0/en/date-and-time-type-overview.html)
DATE - típicamente 3 bytes, rango: 1000-01-01-9999-12-31.DATETIME-8 bytes, rango 1000-01-01 00:00:00 a 9999-12-31 23:59:59TIMESTAMP - 4 bytes oscilan 1970-01-01 00:00:01 UTC a 2038-01-19 03:14:07 UTC. Entonces, hay algunas cuestiones semánticas a tener en cuenta:(int es de 4 bytes como TIMESTAMP, bigint es de 8 bytes como DATETIME)
Me gustaría que hubiera un tutorial válida en la red para CORRECTAMENTE haciendo zonas horarias para los usuarios en MySQL y PHP, parece toda la información es obsoleta ahora que MySQL ha cambiado la el formato de los campos de marca de hora es exactamente el mismo que el de una fecha y hora – JasonDavis