Simplificar query existente para mostrar última programación de etapa

[joseibarz]

Buenas tardes,

Tengo una tabla "programacionEtapas" que está formada tal que:

| id | etapa | fechaIni | fechaFin | createdOn |

de forma que cuando se reprograma una etapa, simplemente añado un nuevo registro, para guardar el histórico de reprogramaciones.

Luego, tengo una vista creada que muestra la fecha de inicio y fin de cada etapa, teniendo en cuenta la última programación (la actual) que se ha añadido para esa etapa, basándome en la mayor fecha del campo "createdOn".

Me da a mi que se puede simplificar bastante esta query, pero no acabo de dar con la fórmula para hacerlo.

Alguien me puede echar una mano?

Muchas gracias.
Saludos.

Código SQL:

SELECT     TOP 100 PERCENT pro.etapa, pro.fechaIni, pro.fechaFin
FROM         dbo.ProgramacionEtapas AS pro INNER JOIN
           (SELECT     p.id FROM dbo.ProgramacionEtapas AS p INNER JOIN
                 (SELECT     TOP 100 PERCENT etapa, MAX(createdOn) AS createdOn
                 FROM          dbo.ProgramacionEtapas
                 GROUP BY etapa) AS s 
           ON p.etapa = s.etapa AND p.createdOn = s.createdOn GROUP BY p.id)
           AS pre ON pro.id = pre.id
 

[iislas]

Para quitarte de problemas, cuando haya una reprogramacion, la fecha createdOn ponla en NULL y en tu select, las eliminas o descartas

[joseibarz]

Hola iislas, gracias por contestar, pero me interesa guardar el dato por temas de históricos. Para saber en qué momento se reprogramó una etapa.

[iislas]

Entonces, agregale una columna de tipo BIT, 0-ausente, 1-presente, SIMPLE....

[joseibarz]

No se os ocurre alguna forma de hacerlo con los datos existentes? Actualmente tengo algo que funciona y no querría complicar la lógica del programa.

Estoy casi convencido de que se debería poder simplificar, me parece muy enrevesada la forma actual.

Gracias.

[gnzsoloyo]

No se os ocurre alguna forma de hacerlo con los datos existentes? Actualmente tengo algo que funciona y no querría complicar la lógica del programa.

SI un cambio estructural menor en la base te complica el programa, tienes un exceso de acoplamiento entre la capa de datos y la capa de negocio.

Hola iislas, gracias por contestar, pero me interesa guardar el dato por temas de históricos. Para saber en qué momento se reprogramó una etapa.

Ese campo no te sirve, así como está, para ese fin, ya que sólo soportaría la existencia de una reprogramación, y no podría darte información histórica si hubiese más de una.
Por otro lado, el que lo pongas en NULL, no invalida tu lógica histórica, porque una etapa con ese campo en NULL es una etapa que jamás fue reprogramada, por lo que no veo el problema, y sí veo ventajas, como te lo plantea @iislas.

No se os ocurre alguna forma de hacerlo con los datos existentes?

El tema es que si la estructura de datos que tienes (la estructura, y no los datos, son cosas diferentes), no es eficiente, o no está bien diseñada, ninguna consulta eficiente y efectiva sale completamente bien. Es difícil optimizar consultas basadas en estructuras inadecuadas.
Mi sugerencia sería que analices si es posible:
1) Separar la fecha de reprogramación a otra tabla (un dato opcional no es bueno que esté en una tabla base).
2) En caso de no poder hacerlo, veas de manejarlo como NULL, cuando no se ha cargado.
3) Desacopla la aplicación de la base. Demasiado acoplamiento genera siempre muchos problemas, entre otras cosas porque genera una dependencia bidireccional nociva.
Recuerdo que mis profesores (tanto de BBDD como de programación) siempre decían: "La aplicación debe poder cambiarse sin que la base de datos se entere, y la base de datos debe poder ser corregida sin que la aplicación deje de funcionar".
¿Se entiende la idea?