El día de hoy tengo una labor medio extraña. Crear un reporte en un colegio de profesionistas, en una nueva pestaña de jquery existente (modificar en cuatro lugares y crear un nuevo archivo php), para poder sacar un reporte filtrado de personas interesadas en inscribirse a el.
El problema es que necesitan filtrar por fecha, pero la tabla no tenía rango de fechas.
De entrada ya metí un campo TIMESTAMP por default cuando entren nuevos datos, pero eso no arregla los problemas anteriores; evidentemente el diseñador de la base de datos original no lo consideró.
Lo ideal sería guardar sin cambios al sistema tanto la fecha de alta del registro (el timestamp ya lo hace), como la del ultimo cambio.
Solo puede haber una Timestamp on update, asi que elegí la de alta. Se podria manejar un trigger a una tabla que actualizara el dato mediante otro trigger al a tabla original (lo he hecho) pero este caso no se puede por una limitación de Mysql así que se van a tener que quedar con solo la fecha de alta, a menos que me paguen por cambiar el código ajeno para hacer el update de los cambios (y no guardaría si se cambia en phpmyadmin)
Considrar una de las limitaciones para MYSQL: Mysql no puede utilizar o desatar triggers para actualizaciones en cascada de llaves foráneas.
Trataré de explicar este problema.
En una empresa x en la que estuve trabajando hace unos años, bajo un motor SQL2000, el área de compras mandaba pedidos de los que después se retractaba o eran con otra fecha. Entonces no era raro que alguien pusiera un pedido con fecha de entrega del 17 de julio, por ejemplo, pero en realidad les fallaba el calculo y el 12 sabían que el 13 de julio se quedaban sin nada. Entonces era práctica común cambiar la fecha de entrega deseada, y era una habilidad perfectamente posible y clara : El 12 decía que lo necesitabn el 13, pero el error humano quedaba oculto.
En su momento contrataron a una de mis PYME para darle mantenimiento/cambios a ese sistema Cuando supe de este problema la función que yo tenía era hacer unos grids que manejaran radio buttons e iconos , pero el problema de cambios de fecha se les estaba saliendo de control.
Mi solución fue :
Triggers de insert, update y delete en todas las tablas de datos, apuntando a una base de datos diferente.
Para que esto funcionara, cada usuario debñia tener un usuario diferente, así que modifique el sistema para crear los usuarios al vuelo en la base datos usando los datos del login, y al salir borrar al usuario de la base de datos.
Ventaja extra: Incluso cambios directos desde el panel de control de mssql quedaban registrados.
Desventaja 1: Cambios a la estructura de una tabla implicaban borrar relaciones a mano, borrar triggers, rediseñar los triggers, recrear relaciones a mano. Un campo nuevo en tablas de vistas, podía tardar casi cuatro horas.
Desventaja 2: Esa base de datos usaba actualizaciones en cascada (lo cual me parece una estupidez por integridad referencial y problemas de borrado en cascada no deseado ), y eso no se hubiese podido hacer en mysql.
Problema actual:
la base de datos del colegio está en MYISAM, el sistema se mantiene por pincitas por unos queries que usan insert into, y hay borrados en cascada.
Probablemente usar un sistema de triggers funciona mejor con sistema ya probado y al que no tiene sentido cambiar la estructura. Otra es crear un creador automático de triggers al vuelo, que ya hice pero que dejé en stand by cuando recordé que Mysql no acepta triggers bajo ordenes en cascada