En la siguiente pregunta, los nombres de campos y tablas se han cambiado para proteger sus identidades.
Si tengo dos columnas de base de datos:
MONKEY_DATE DATETIME NULL (with data e.g. 2012-05-14 00:00:00.000)
MONKEY_TIME DATETIME NULL (with data e.g. 1753-01-01 16:30:53.025)
El componente de fecha del campo de tiempo se establece principalmente en 1 de enero de 1753 ... pero algunos datos tienen el 1 de enero de 1899 y algunos tienen el 1 de enero de 1900.
Me parece que mantener el código para consultar e informar sobre estas columnas me causa a mí (y a nuestro equipo) un dolor de cabeza que podría resolverse fácilmente fusionando las dos columnas. Sin embargo, la experiencia (y Terry Goodkind ) me ha enseñado que nada es fácil. Vea a continuación algunos ejemplos de por qué esto es un dolor de cabeza.
Mi acercamiento
Estoy pensando que el siguiente enfoque tendrá el efecto deseado de fusionar las dos columnas:
- Use SQL para actualizar los datos, estableciendo el valor para el campo de fecha y el valor para el campo de tiempo en el mismo valor, que es una combinación del componente de fecha del campo de fecha y el componente de tiempo del campo de tiempo
- Escriba cualquier código nuevo solo usando el campo MONKEY_DATE
- Finalmente, elimine gradualmente el campo MONKEY_TIME y cualquiera de los componentes SQL de fecha / hora (ver ejemplos)
- Soltar MONKEY_TIME
Esto significa que no tenemos que realizar cambios retrospectivos en todo el sistema de inmediato ... todo el código existente continuará funcionando ... y podemos comenzar a hacer las cosas de la manera correcta.
SQL para # 1 podría ser (Oracle):
UPDATE MONKEY SET
MONKEY_DATE = TO_DATE(TO_CHAR(MONKEY_DATE, 'MM/DD/YYYY ') ||
TO_CHAR(MONKEY_TIME, 'HH24:MI:SS'),
'MM/DD/YYYY HH24:MI:SS')
MONKEY_TIME = TO_DATE(TO_CHAR(MONKEY_DATE, 'MM/DD/YYYY ') ||
TO_CHAR(MONKEY_TIME, 'HH24:MI:SS'),
'MM/DD/YYYY HH24:MI:SS')
La pregunta
Mis preguntas para usted son:
- ¿Deben fusionarse estos campos?
- ¿Es razonable mi enfoque para fusionar estas dos columnas?
- ¿Crees que sería mejor omitir los pasos dos y tres?
- ¿Tiene algún otro comentario (constructivo) o sugerencia?
Ejemplos
Por ejemplo, para seleccionar todas las fechas y horas de mi mono y ordenarlas por fecha y hora, necesito hacer algo como esto (SQL Server):
SELECT
CONVERT(DATETIME, CONVERT(VARCHAR, MONKEY_DATE, 101), 101) AS MONKEY_DATE
, CONVERT(DATETIME, CONVERT(VARCHAR, MONKEY_TIME, 108), 108) AS MONKEY_TIME
FROM MONKEY
ORDER BY
CONVERT(DATETIME, CONVERT(VARCHAR, MONKEY_DATE, 101), 101) DESC
, CONVERT(DATETIME, CONVERT(VARCHAR, MONKEY_TIME, 108), 108) DESC
o esto (Oracle - un poco más explícito):
SELECT
TO_DATE(TO_CHAR(MONKEY_DATE, 'MM/DD/YYYY'), 'MM/DD/YYYY') AS MONKEY_DATE
, TO_DATE(TO_CHAR(MONKEY_TIME, 'HH24:MI:SS'), 'HH24:MI:SS') AS MONKEY_TIME
FROM MONKEY
ORDER BY
TO_DATE(TO_CHAR(MONKEY_DATE, 'MM/DD/YYYY'), 'MM/DD/YYYY') DESC
, TO_DATE(TO_CHAR(MONKEY_TIME, 'HH24:MI:SS'), 'HH24:MI:SS') DESC
También a menudo me encuentro seleccionando una columna de fecha / hora fusionada (Oracle):
SELECT
TO_DATE(TO_CHAR(MONKEY_DATE, 'MM/DD/YYYY ') ||
TO_CHAR(MONKEY_TIME, 'HH24:MI:SS'),
'MM/DD/YYYY HH24:MI:SS') AS MONKEY_DATE_TIME
FROM MONKEY
Porque, casi todo el tiempo, queremos saber la fecha y hora del mono.
El SQL anterior podría modificarse fácilmente para:
SELECT MONKEY_DATE_TIME FROM MONKEY ORDER BY MONKEY_DATE_TIME... Si tan solo hubiéramos fusionado columnas.
Antecedentes
Heredé un antiguo sistema ASP que almacena fechas y horas en columnas separadas en la base de datos. Me han dicho que esto probablemente se deba a que la aplicación comenzó en una versión anterior de Access, donde no era posible almacenar la fecha y la hora en la misma columna. Los porqués y los cómo no son realmente parte de esta pregunta, pero a algunas personas les gusta saber.
PD
Realmente casi publiqué esto en SO.SE, así que mis disculpas si obtuve el sitio equivocado.