Cita: 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.
Cita: 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.
Cita: 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?