En una base de datos, ¿usaría un campo de fecha o campos de año y mes si solo necesita año y mes?

Question

Estoy configurando una tabla donde necesito el año y el mes. En MySQL creo que tengo 2 opciones: (1) 2 campos: 1 por año, 1 por mes o (2) un campo de fecha (el día siempre será 1).

Los 2 campos tienen la ventaja de ser algo más rápidos (creo) porque MySQL no tiene que convertir el valor de una fecha a un número entero, aunque esto es probablemente insignificante. El campo de fecha tiene la ventaja de la validación "automática": alguien no puede obtener datos en el DB con el mes siendo 13 o el año 1. Con un campo de fecha también puede hacer los cálculos de fecha más fácilmente (es decir, meses entre)

¿Cuál usarías? ¿O hay otro que usarías?

Answer 1

Utilice un campo de fecha. Dado que sql admite campos de fecha de forma nativa, es fácil filtrar fechas específicas mediante la cláusula WHERE.

Los 2 campos tiene la ventaja de ser un poco más rápido de lo [...]

Su consulta SELECT no es su cuello de botella por lo que no debe preocuparse por esto. La legibilidad y un programa pragmático es más importante que un "cuello de botella percibido".

Answer 2

Si va a ejecutar muchas operaciones en el campo de fecha, lo separaré en columnas separadas y manejaré la validación de datos en una restricción de tabla o en el DAL.

Por ejemplo, crear informes de ventas por día, mes y año es mucho más eficiente cuando los campos están divididos. La razón es que no tiene que usar las funciones de fecha y hora para desglosar la fecha de agrupación.

Si es algo así como un cumpleaños en el que podría consultarlo de vez en cuando, entonces no me preocuparía y simplemente lo dejaría en un campo de fecha.

Answer 3

Utilizaría el campo de fecha incluso si solo necesita el año y el mes en el que no pierde nada reuniendo todos los datos. Como práctica habitual, siempre reúno toda la información siempre que sea posible.

Answer 4

Probablemente no porque el tipo de datos de fecha y hora más pequeño en SQL Server (Microsoft) es smalldatetime que tiene 4 bytes de longitud. Si solo necesita mes y año, necesita 1 byte por mes y 2 bytes por año.

Answer 5

Utilizaría columnas separadas, principalmente porque eso permitiría un mejor uso de los índices. Por ejemplo, no creo que un índice en una columna de fecha y hora le ayude si solo le preocupan los datos de un mes determinado (no de un año).

Answer 6

Aunque no inmediatamente de utilidad para usted, IBM Informix Dynamic Server es compatible con el tipo:

DATETIME YEAR TO MONTH 

Esto almacena exactamente lo que quieren - el año y mes. Tiene sus usos. La familia de tipos DATETIME incluye muchos otros tipos que ocasionalmente tienen sus usos, y algunos que son de utilidad marginal, siendo el ejemplo canónico DATETIME MONTH TO MINUTE. (La desventaja del tipo son las notaciones detalladas necesarias para manipularlo, pero hay muchas operaciones que se pueden realizar en uno o todos los tipos DATETIME.)

En muchos DBMS, puede colocar restricciones en las columnas, por lo si utiliza un enfoque de dos columnas, debe colocar una restricción CHECK(month_column BETWEEN 1 AND 12) en la columna para asegurarse de que el usuario no haya colocado un valor no válido en la tabla.Incluso puede aplicar una restricción en la columna del año también.

Además, algunos DBMS le permiten crear tipos definidos por el usuario, y un tipo de año-mes es bastante directo a medida que avanza. Los detalles dependen del DBMS, por supuesto.

Answer 7

A menos que haya un beneficio de rendimiento específico de almacenar el año y el mes por separado, me quedaré con la fecha. Con respecto a la indexación, si tiene dos columnas, deberá crear un índice en la combinación de columnas en lugar de uno para la columna de fecha. La fecha se convertirá internamente en un valor largo, por lo que el espacio de almacenamiento requerido no es realmente un problema.

Además, piense en el posible dolor de mantenimiento con dos campos. Tendría dos campos db, posiblemente dos campos en un objeto o la necesidad de construir/analizar mes y año desde/hacia el db. Mantenlo simple con una fecha y deja que el DB haga un seguimiento de tu integridad de datos.

Trabajo con datos como los que describió, fechas de vencimiento en las que el día es siempre el último día del mes, por lo que solo necesitamos mes y año. Almacenamos estos como una fecha.

Answer 8

Mantendré una columna de fecha y hora y dos columnas calculadas con mes y año (indexadas por supuesto). Ten mi pastel y cómelo también :)

Answer 9

Si anticipas consultas sobre el formulario "Dame todas las filas en julio, independientemente del año", será un poco más fácil escribirlas con columnas separadas de meses y años. Un índice separado para la columna del mes debería hacerlo más rápido.

De lo contrario, me gustaría ir a la columna de fecha única: funcionan las funciones simples, entendidas, integradas de validación y fecha. Su única preocupación es que alguien nuevo en el diseño se pregunte por qué todo ocurre siempre el primer día del mes.

Hay otra razón para usar columnas separadas de mes y año con las que me he encontrado: cuando no se conoce el mes. Lo he usado para aplicaciones que permiten que un próximo evento sea "en algún momento de 2009". En ese caso, usar un NULL en la columna del mes resuelve el problema muy bien. No hay una manera fácil de hacerlo con una columna tipo fecha a menos que se te ocurra algún truco horrible como el 2 de enero significa que el mes es desconocido.

Answer 10

Piénselo de esta manera: un día alguien vendrá a usted con un requerimiento de mejorar la aplicación con la capacidad no solo de ahorrar año y mes, sino también un día. ¿Agregarías una columna adicional por un día? Y luego, lo siguiente, es posible que también quieran que ahorres tiempo.

¿Qué tan fácil sería mejorar la funcionalidad si tiene columnas separadas para año/mes/día? Si tiene una sola columna de fecha?

Me gustaría ir a una columna de fecha solo por esta razón.