Cuándo utilizar VARCHAR y FECHA/DATETIME

Question

así que tuvimos esta discusión de programación en Freenode y esta cuestión surgió cuando yo estaba tratando de utilizar un VARCHAR (255) para almacenar una variable de fecha en este formato: D/MM/AAAA. Entonces, la pregunta es por qué es tan malo usar VARCHAR para almacenar la fecha. Ella son las ventajas:

1. Su más rápido al código. Anteriormente utilicé DATE, pero el formato de fecha fue un verdadero dolor.
2. ¿Está más hambriento de energía para usar cuerdas que la Fecha? A quién le importa, vivimos en la era Ghz.
3. No es éticamente correcta (lolwut?) Esto es lo que me dijo el otro usuario ...

Entonces, ¿qué preferiría usted utilizar para almacenar una fecha? SQL VARCHAR o SQL DATE?

Answer 1

Cuando usted tiene la base de datos con más de 2-3 millones de filas que va a saber por qué es mejor usar DATETIME de VARCHAR :)

respuesta simple es que con bases de datos - la potencia de procesamiento no es un problema nunca más. Solo el tamaño de la base de datos se debe al tiempo de búsqueda del HDD.

Básicamente con discos duros modernos se puede leer alrededor de 100 registros/segundo si se leen en orden aleatorio (suele ser el caso) por lo que tienen que hacer todo lo posible para minimizar el tamaño del DB, porque:

• El cabezas de HDD no tendrán que "viajan" esto mucho
• podrás guardar más datos en la memoria RAM

al final siempre HDD de los tiempos de búsqueda que te va a matar. P.ej. algunas consultas simples de GROUP BY con muchas filas pueden tomar un par de horas cuando se realiza en el disco en comparación con un par de segundos cuando se realiza en RAM => debido a los tiempos de búsqueda.

Para VARCHAR no puede hacer ninguna búsqueda. Si odias la forma en que SQL maneja tanto las fechas, solo usa la marca de tiempo unix en el campo entero de 32 bits. Tendrás (básicamente) todas las ventajas de usar el campo SQL DATE, solo tendrás que manipular y formatear las fechas usando tu lenguaje de programación elegido, no las funciones de SQL.

Answer 2

Dos razones:

• ordenar los resultados por parte de las fechas
• No sensibles a formato fecha cambia

Así que tomemos por ejemplo un conjunto de registros que tiene este aspecto:

5/12/1999 | Frank N Stein 
1/22/2005 | Drake U. La 
10/4/1962 | Goul Friend 

Si nos vamos a almacenar los datos de su camino, pero lo arreglaron en las fechas en assending o rder SQL responderá con el conjunto de resultados que tiene este aspecto:

1/22/2005 | Drake U. La 
10/4/1962 | Goul Friend 
5/12/1999 | Frank N. Stein 

Donde si nos guardaron las fechas como DATETIME, SQL responderá correctamente ordenándoles así:

10/4/1962 | Goul Friend 
5/12/1999 | Frank N. Stein 
1/22/2005 | Drake U. La 

Además, si en algún lugar de el camino que necesitaba para mostrar las fechas en un formato diferente, por ejemplo, YYYY-MM-DD, entonces necesitaría transformar todos sus datos o tratar con contenido mixto. Cuando se almacena como una FECHA SQL, se lo fuerza a hacer la transformación en código, y muy probablemente tenga un punto para cambiar el formato para mostrar todas las fechas, de forma gratuita.

Answer 3

Por qué no poner los tornillos con un martillo?

Porque no es la herramienta adecuada para el trabajo.

Algunas de las desventajas de la versión VARCHAR:

• No se puede agregar fácilmente/restar días a la versión VARCHAR.
• Es más difícil de extraer solo mes/año.
• No hay nada que le para poner los datos no fecha en la columna VARCHAR en la base de datos.
• La versión VARCHAR es específica de cada cultivo.
• No puede ordenar las fechas fácilmente.
• Es difícil cambiar el formato si quieres más tarde.
• Es poco convencional, lo que hará que sea más difícil para otros desarrolladores a entender.
• En muchos entornos, el uso de VARCHAR usará más espacio de almacenamiento. Esto puede no importar para pequeñas cantidades de datos, pero en entornos comerciales con millones de filas de datos esto podría hacer una gran diferencia.

Por supuesto, en sus proyectos de hobby puede hacer lo que quiera. En un entorno profesional, insisto en usar la herramienta adecuada para el trabajo.

Answer 4

Entre DATE/DATETIME y VARCHAR para las fechas Me gustaría ir con DATE/DATETIME cada vez. Pero hay una tercera opción pasada por alto. ¡Almacenándolo como INTEGER sin firmar!

Decidí ir con INTEGER unsigned en mi último proyecto, y estoy muy satisfecho de tomar esa decisión en lugar de almacenarla como DATE/DATETIME. Debido a que estaba pasando las fechas entre el cliente y el servidor, fue el tipo ideal para usar. En lugar de tener que almacenarlo como DATE y tener que convertir de nuevo cada vez que selecciono, simplemente lo selecciono y lo uso como yo quiera. Si desea seleccionar la fecha como fecha de "lectura humana", puede usar la función FROM_UNIXTIME().

También un número entero ocupa 4 bytes, mientras que DATETIME ocupa 8 bytes. Ahorro de 50% de almacenamiento.

El problema de clasificación que Berin propone también se resuelve utilizando enteros como almacenamiento para las fechas.

Answer 5

Yo votaría por usar los tipos de fecha/fecha y hora, solo por simplicidad/coherencia.

Si lo hace almacenarla como una cadena de caracteres, almacenarlo en ISO 8601 formato:

• http://www.iso.org/iso/date_and_time_format
• http://xml.coverpages.org/ISO-FDIS-8601.pdf
• http://www.cl.cam.ac.uk/~mgk25/iso-time.html

Entre otras cosas, la norma ISO 8601 de fecha/hora la secuencia (A) se clasifica adecuadamente, (B) son legibles por el ser humano, (C) son independientes de la configuración regional y (D) son fácilmente convertibles a otros formatos. A la cuna de la propaganda de la ISO, ISO 8601 cadenas ofrecen

representaciones de lo siguiente:

• Fecha
• hora del día
• Tiempo Universal Coordinado (UTC)
• Hora local con respecto al UTC
• de fecha y hora
• Los intervalos de tiempo
• intervalos de tiempo recurrentes

representaciones pueden estar en uno de dos formatos: un formato básico que tiene un número mínimo de caracteres y un formato extendido que añade caracteres para mejorar la legibilidad humana. Por ejemplo, el 3 de enero de 2003 se puede representar como 20030103 o 2003-01-03.

[y]

ofrecen las siguientes ventajas con respecto a muchos de los localmente utiliza representaciones:

• fácilmente legible y escribible por los sistemas
• fácilmente comparables y se puede ordenar
• Idioma independientes
• Las unidades más grandes se escriben delante de las unidades más pequeñas
• Para la mayoría de las representaciones de la notación es corto y de longitud constante

Una última cosa: Si todo lo que necesita hacer es almacenar una fecha y después almacenarlo en la norma ISO 8601 forma corta AAAAMMDD en un char (8) la columna no necesita más almacenamiento que un valor de fecha y hora (y no tiene que preocuparse por la brecha de 3 milisegundos entre el último tic del día y el primer tilde del siguiente. Pero ese es un asunto para otra discusión. Si lo divide en 3 columnas — YYYY char(4), MM char(2), DD char(2), utilizará la misma cantidad de almacenamiento y obtendrá más opciones para indexar. Mejor aún, almacene los campos como un abreviatura de yyyy (4 bytes), y una minúscula para cada uno de MM y DD — ahora tiene una longitud de hasta 6 bytes para la fecha. El inconveniente, por supuesto, de descomponer los componentes de fecha en sus partes constituyentes es que la conversión a tipos de datos de fecha/hora adecuados es complicada.