¿Hay alguna buena razón para mantener la fecha y la hora en columnas separadas?

Estoy tratando de entender la decisión de nuestro proveedor de software de mantener la fecha y la hora en columnas separadas. Por ejemplo, cuando se creó o actualizó la fila. Tanto la hora como la fecha son columnas DateTime. Estamos usando SQL Server 2005.

La base de datos contiene los datos de nuestro sistema ERP y creo que las tablas más grandes contienen aproximadamente ~ 3 millones de filas. La mayoría de las tablas son aproximadamente entre 100 000 y 1 000 000 de filas.

Personalmente, de forma predeterminada, elegiría un único DateTime para una sola marca de tiempo. Esto permitiría cálculos de diferencia de tiempo más fáciles y las partes de fecha y hora podrían extraerse fácilmente de la marca de tiempo. También consumiría menos espacio.

¿Separar la fecha y la hora es una mala práctica o hay algo muy brillante en este diseño que no entiendo?

Supongo que es una cuestión de soporte heredado (es decir, en la versión 1 de su software, tenían fecha y hora en campos separados y se vieron obligados a admitirlo porque siempre funcionó de esa manera).

Dicho esto, no hay nada brillante en separar la fecha y la hora, por lo que no hay nada que te falte.

(La otra opción es que los desarrolladores de su sistema ERP no sabían que un campo de fecha y hora puede almacenar una fecha y una hora, pero es mucho más probable que tengan un requisito comercial para que funcione igual que las versiones anteriores).

En general, depende del uso. Si muchas consultas están uniendo subelementos, considere almacenarlos juntos y luego asumir la responsabilidad de tener que separarlos en esas ocasiones más raras. Por supuesto, la división a veces es más compleja (o imposible): considere un person_full_nameatributo del que necesita extraer person_family_name. Dicho esto, emitir un valor temporal es trivial, por lo que generalmente preferiría almacenar la fecha y la hora juntas.

También considere almacenar tanto juntos como separados, con restricciones (y tal vez desencadenantes) para garantizar que no se desincronicen: de esta manera, usted asume el éxito de dividir / unir en el punto de actualización en lugar de en el momento de consultar el datos.

No puedo ver mucho uso de esto en un sistema operativo. En un sistema analítico, es posible que desee una dimensión de fecha separada con una gran cantidad de "días" para que la fecha se vincule a los informes acumulados de fecha, y tal vez una columna de "hora" si desea hacer un análisis por hora del día por alguna razón .

También puede presentar la fecha y la hora como columnas calculadas en función de una columna central de fecha y hora.

Para agregar al comentario de ConcernedOfTunbridgeWe, existe una ventaja en el rendimiento de las consultas si tiene una tabla DateDimension y TimeDimension. Considere que la tabla de hechos tiene dateDimensionKey y TimeDimensionKey. Si desea encontrar la cantidad de algo entre las 8 am y las 5 pm, simplemente puede hacer

SELECT COUNT(1) FROM FactTable f Inner Join TimeDimension t on f.TimeDimensionKey = t.TimeDimension WHERE t.Hour BETWEEN 8 AND 17.

Si ha agregado un índice a TimeDimensionKey, solo necesitará una búsqueda de índice para el resultado en su tabla de hechos para buscar datos

Sin la tabla TimeDimension, tendrá que hacer algo como lo siguiente,

SELECT COUNT(1) FROM FactTable f WHERE DatePart(mintue, f.Date) BETWEEN 8 AND 17

Esto probablemente requerirá un escaneo de la tabla porque el motor de la base de datos necesita calcular el resultado para cada fila antes de que pueda determinar qué datos se pueden devolver.