enviar registros de una tabla a un campo de otra tabla a travez de ciclo IF en MYSQL

[[Delphius]]

Ummm, no veo que funcione adecuadamente ese Trigger.
Por empezar supuse que te darías cuenta que necesitas de una tabla más.

Te explico:
Según tu explicación, tu tabla Auditoria tiene los siguientes campos:
tabla
campo
valor anterior
valor actual
etc...

Esto me da la pauta de que por cada campo de interés por auditar se debe insertar un registro en dicha tabla.
Ahora bien, la pregunta aquí es ¿Y que sucede si alguien hace modificaciones a más de un campo de alguna tabla a la que se le lleve el proceso de auditoria? Mejor dicho, la pregunta sería ¿De qué manera identificamos cuales son los cambios que pertenecen a un mismo registro, a una misma acción?

Es necesario contar con un esquema maestro-detalle para conseguir esto. Por ejemplo: una tabla maestra llamada Auditoria que contenga los campos:
IDAuditoria -> PK
Fecha/Hora
Nombre_tabla
IDregistro
etc

Y una tabla Auditoria_detalle, cuyos campos serían en este caso:
IDAuditoria_detalle -> PK
AuditoriaID -> FK
campo
ValorActual
valorAnterior

¿Porqué este esquema? Porque de esta manera conseguimos identificar todos los cambios realizados para un mismo registro de alguna tabla.

De este modo, ante el disparo de algún trigger, realizamos un INSERT dentro de éste en las tabla de detalles, por cada campo que necesitamos auditar.

Tal vez este hilo te sea de ayuda para comprender mejor el panorama.

Saludos,

[CLUSTERBIT]

Empezado por Delphius

Ummm, no veo que funcione adecuadamente ese Trigger.
Por empezar supuse que te darías cuenta que necesitas de una tabla más.

Te explico:
Según tu explicación, tu tabla Auditoria tiene los siguientes campos:
tabla
campo
valor anterior
valor actual
etc...

Esto me da la pauta de que por cada campo de interés por auditar se debe insertar un registro en dicha tabla.
Ahora bien, la pregunta aquí es ¿Y que sucede si alguien hace modificaciones a más de un campo de alguna tabla a la que se le lleve el proceso de auditoria? Mejor dicho, la pregunta sería ¿De qué manera identificamos cuales son los cambios que pertenecen a un mismo registro, a una misma acción?

Es necesario contar con un esquema maestro-detalle para conseguir esto. Por ejemplo: una tabla maestra llamada Auditoria que contenga los campos:
IDAuditoria -> PK
Fecha/Hora
Nombre_tabla
IDregistro
etc

Y una tabla Auditoria_detalle, cuyos campos serían en este caso:
IDAuditoria_detalle -> PK
AuditoriaID -> FK
campo
ValorActual
valorAnterior

¿Porqué este esquema? Porque de esta manera conseguimos identificar todos los cambios realizados para un mismo registro de alguna tabla.

De este modo, ante el disparo de algún trigger, realizamos un INSERT dentro de éste en las tabla de detalles, por cada campo que necesitamos auditar.

Tal vez este hilo te sea de ayuda para comprender mejor el panorama.

Saludos,

Delphius gracias por el hilo y fuiste certero eso es lo que realmente tengo que hacer
pero confiezo que no tengo mucho conocimiento de bases de datos (no hago diferencia de mysql y sql ya que la sintaxis es similar)

y esta es la tabla completa

ts_auditoria

AUDI_ID
AUDI_IP
AUDI_FECHA
AUDI_TABLA
AUDI_CAMPO
AUDI_VALOR_ANTERIOR
AUDI_VALOR_ACTUAL

ahi esta completa en cuanto al trigger quizas con un pequeño ej me podria orientar mejor

saludos y gracias por el interes en ayudar

[[Delphius]]

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,

[CLUSTERBIT]

Delphius ahora me ha quedado mas claro muchas gracias espero no haberte molestado
me as sido de mucha ayuda

gracias

saludos en cuanto a lo de "flojo" jejeej... (ahy veces en que las criticas hacen bien)