Ver Mensaje Individual
  #8  
Antiguo 23-10-2008
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Reputación: 25
Delphius Va camino a la fama
Hola CLUSTERBIT,
El ejemplo que se ve en el hilo que te pasé corresponde a Firebird. Como he dicho antes, no se MySQL, por lo que no me atrevería a ofrecerte algún ejemplo. No creo que sea tanta la diferencia con respecto a Firebird.

Buscando en la red de redes se puede hallar algo ¿no crees? Por ejemplo aqui muestra unos ejemplos bastantes simples, y aqui hay una explicación más profunda.

Básicamente consiste en armar sentencias SQL y operar con las variables NEW y/o OLD según sea el caso dentro del Triggers.

Con respecto a la estructura de tu tabla, me parece que no entendiste lo que he dicho anteriormente. Bajo tu diseño conseguirás información redundante.

Lo más adecuado es tener dos tablas de auditoria, una auditoria_maestra que resuma e identifique a la acción invocada y otra tabla auditoria_detalle que registre cada cambio realizado. Pongamos un ejemplo más claro: tenemos un Trigger AFTER UPDATE para una tabla llamada PERSONAS. La tabla tiene los siguientes campos:
IDPersona -> PK: Primary key
Nombre
Apellido
Telefono
Domicilio
Razon Social

Supongamos que para el proceso de auditoria le es de importancia resguardar los datos relacionados con el teléfono, el domiciio y la razón social (muy difícil, o poco probable de que el se cambie el nombre o el apellido). Por tanto, definimos una tabla llamada AUDITORIA. Los campos fueran los siguientes:
IDAuditoria -> PK: Primary Key
IDPersona
Tabla
Campo
Valor Anterior
Valor Nuevo

Hagamos de cuenta que existe este registro:
1 - Pepe - López - 123456 - Calle 1 casa 2 - Razon Pirulo

Y por algún motivo esta persona se muda y cambia su razón social:
1 - Pepe - López - 789654 - Calle 100 casa 50 - Razon Pirulo Deluxe

El trigger debería crear los siguientes registros:
1 - 1 - Personas - Telefono - 123456 - 789654
2 - 1 - Personas - Domicilio - Calle 1 casa 2 - Calle 100 casa 50
3 - 1 - Personas - Razon Social - Razon Pirulo - Razon Pirulo Deluxe

La pregunta aquí es ¿cómo identificas que estos tres cambios pertenecen a una misma acción y no a distintas acciones, de distintos momentos?

Tu me dirás, fácil: añado un campo fecha/hora. ¿A si? veamos...
1 - 22/10/2008 22:00:01 - ....
2 - 22/10/2008 22:00:02 - ...
3 - 22/10/2008 22:00:03 - ...

En realidad seguimos en la misma. ¿Porqué? Por que simplemente ese campo fecha/hora no es lo suficientemente confiable como para garantizar de que estos tres cambios corresponde a una sola acción hecha por el usuario. Además, si te fijas tenemos información redundante.

Lo correcto es tener la información desglosada en dos. Por un lado la información correspondiente al momento y al tipo de acción realizada por el usuario (tabla maestra), y por el otro la información detallada de las operaciones que conforman a dicha acción (tabla detalle). Entonces ahora tenemos una tabla AUDITORIA_MAESTRO, cuyos campos son:
IDAuditoria -> PK
Fecha/Hora
Tabla -> Nombre de la tabla
IDRegistro -> guardará el ID del registro en el que se llevó a cabo la acción
TipoAccion -> Podría ser un valor entero: 1->Alta, 2->Baja, 3->Modificación

Eso es como mínimo. Tal vez (muy posiblemente) se deba identificar al usuario, por tanto se añadiría un campo IDUsuario.

Y ahora la tabla AUDITORIA_DETALLE cuyos campos son:
IDAuditoriaDetalle -> PK: clave primaria
IDAuditoria -> FK: clave foranea, apunta al campo IDAuditoria de la Maestra
NombreCampo
ValorAnterior
ValorNuevo

Entonces ahora si estamos en condiciones de tener la información correctamente estructurada. El resultado de esta operación quedaría así:

Maestro:
1 - 22/10/2008 22:00 - Personas - 1 - 3

Detalle:
1 - 1 - Telefono - 123456 - 789654
2 - 1 - Domicilio - calle 1 casa 2 - calle 100 casa 50
3 - 1 - Razon Social - Razon Pirulo - Razon Pirulo Deluxe

¿Y si el usuario sólo necesita cambiar uno solo de los campos? Pues, si se ha diseñado adecuadamente las instrucciones del trigger, se obervaría algo como esto:

1 - 1 - CampoDelCambio - ElValorViejo - ElValorNuevo

¿Se entiende la diferencia entre mi diseño y el tuyo?
Ahora una anotación. ¿Es necesario guardar el nombre de la tabla donde realizamos las acciones? De igual modo, ¿Es necesario el nombre del campo?
La respuesta es un gran depende.
Si sólo vamos a llevar un proceso de auditoria sencillo, y que posiblemente sólo se aplique en una sola tabla (la cual es fácilmente identificable) muy posiblemente podemos olvidar de dicho campo. De igual modo, sólo tiene sentido guardar el nombre de los campos sólo si es necesario identificarlo de los otros.

Ahora la pregunta final ¿Y es necesario tener la tabla maestra y detalle? No necesariamente. Si, he hecho un gran post mostrando lo contrario, pero en realidad esto responde a una necesidad y una conveniencia.

Podríamos argumentar que si hay pocas tablas y pocos cambios y el proceso de auditoria no es bastante riguroso y no va a sufrir grandes cargas de datos, tal vez nos podemos evitar esas tablas maestras y detalles y tener todo en un sólo lado.

En fin, todo se resume a un correcto estudio de la situación.
¿Porqué te solté este rollo de hilo? Porque te noté un tanto flojo en esto, y es necesario que analices objetivamente tus requisitos, necesidades y restricciones técnicas y operativas.

La pregunta inicial que debes hacerte es ¿Porqué auditar? La respuesta a esa pregunta debería servirte para saber que tan complejo o sencillo debería ser el diseño de tu base de datos.

Podría ser muy simple, o muy complejo según lo mires.

Espero que se entienda ahora mejor el tema y la magnitud de lo que encierra.

Saludos,
__________________
Delphius
[Guia de estilo][Buscar]
Responder Con Cita