Registros no actualizados. Saber cuáles

[gnzsoloyo]

En esencia, lo que planteas es crear un sistema de auditoría sobre tu base, cosa que como no es parte de los recursos de MySQL, tendrás que crear por tí mismo y para tu propósito. No veo otras soluciones.
Algunos de los detalles que hay que tener en cuenta para poder diseñarlo son:
- Cada ejecución de una consulta de INSET/UPDATE/DELETE sobre una tabla y un registro devuelve una cantidad de registros afectados iguala 1. Pero no devuelve qué campos se afectaron en esa consulta.
- Una consulta de INSET/UPDATE/DELETE de múltiples registros nos informa la cantidad de registros afectadas, pero no permite establecer qué registros fueron los afectados, por lo cual solamente un INSET/UPDATE/DELETE individual serviría para una auditoría.
- El único modo de capturar la acción de modificación de registros por medio de INSET/UPDATE/DELETE sería usando TRIGGERS, siemrpe y cuando no haya TRIGGERS definidos para esos eventos en las tablas, caso en el cual la auditoría debería estar integrada a los mismos.
- Aún cuando se pudiese hacer por TRIGGERs, eso implicaría definir TRIGGERs para cada tabla. Huelga decir que eso impactará en la performance negativamente.
- Si los valores a cambiar no son siempre los mismos, habría que registrar los dos estados, porque no hay forma de hacer un TRIGGER que "adivine", a priori cuál es el valro que está ingresando, y además no puedes recorrer la estructura de la tabla que estás modificando, al menos no en MySQL. En otras palabras, INSET/UPDATE/DELETE dinámicos no se pueden adminsitrar fácilmente con TRIGGERS, por lo que solamente podrías intentarlo con stored procedures, con la limitación de que en un SP no hay parámetros opcionales, por lo que deberías enviar todos y resolver la inserción/actualización en forma dinámica por dentro del SP... lo que sería demasiado complicado.
- Por otro lado, que un registro no sea afectado no implica que haya un error (que de por sí es un evento detectable), sino por otras causas como por ejemplo que el valor ya exista en la tabla y en ese campo, o porque el registro buscado no existe; ninguna de las dos son errores desde ese punto de vista.

En definitiva, lo que yo considero viable es crear una tabla de auditoría donde se pueda almacenar, a través de la aplicación, los parámetros enviados a la consulta en aquellos casos en que la consulta modifique registros, de modo de poder revisarlos como tabla. Lo que veo difícil es el modo de hacer una consulta que te devuelva exactamente qué campos no fueron afectados en un registro dado, o si el registro no fue afectado porque no había cambios que debieran hacerse.