Llego tarde al tema, pero la idea que propone Mario (
mamcx) es sin duda la manera mas adecuada. Lo que el propone se conoce (o al menos, Martin Fowler le pone este nombre) como
Event Sourcing. En ese link, el propio Fowler da una introduccion al tema y explica como implementarlo.
El articulo esta en ingles, y como se trata de Fowler, se habla pura y exclusivamente de objetos (POO), pero el concepto es el mismo asi se implemente a nivel BD (usando triggers o disparadores, por ejemplo)
La idea general de Event Sourcing es que todo lo que sea transformaciones de estado (agregar, actualizar o borrar) sea capturado por objetos que el define como "Event Objects". Estos objetos lo que hacen es ir "apilando" los cambios uno atras de otro, llevando un changelog, es decir, en lugar de tener el "ultimo estado" per se, se tiene un registro. Luego para obtener el estado actual, la aplicacion deberia levantar el log, e ir aplicando en orden todos los cambios hasta el ultimo. Tambien explica que esto podria ser lento si son muchos registros para procesar, y como hacer para solucionarlo
Este diseño lleva a varias ventajas:
- Poder reconstruir el estado de la aplicacion: Simplemente levantas todo el log y aplicas todos los cambios a una aplicacion "vacia"
- Consultas a lo largo del tiempo: Es posible preguntar cual era el estado en cualquier fecha, ya que tu aplicacion es capaz de reconstruirse desde el inicio hasta cualquier fecha determinada
- Se pueden revertir cambios: Si una serie de eventos tuvo algun resultado incorrecto, se puede volver al estado inicial "deshaciendo" los eventos en orden inverso, volviendo al estado correcto y a su vez llevando el registro de lo incorrecto
Ejemplos de este tipo de sistema son los que se encargan de versionar el codigo fuente. Git, subversion, mercurial, permiten ver una "foto" de como era tu codigo exactamente hace un año, por ejemplo.