|
enviar registros de una tabla a un campo de otra tabla a travez de ciclo IF en MYSQL
hola les agradeseria si me ayudaran con esto
tengo que extraer los campos de una tabla o registros de una tabla esto lo quiero hacer a traves de un ciclo if en mysql cosa que tome los registros y se copien en el campo de otra tabla supongamos que tenenmos tabla: personas y sus campos son: rut,nombre,apellido_paterno,apellido_materno etc... tabla: auditoria y sus campos son: tabla,campo,valor_anterior,valor_actual etc... en la tabla auditoria y dentro de sus campos necesito que se copien los registros ingresados en la tabla personas he tratado con varias formas pero nada me resulta asumo que es con un IF pero nose como situarlo en la consulta quizas ustedes me podrian dar una mano si es que es posible |
Hola CLUSTERBIT,
La verdad es que no comprendo que tiene que ver el IF en todo esto. No se si estoy interpretando erroneamente tu duda, pero creo que bastaría con ejecutar una cosulta SQL como de este tipo:
Saludos, |
Cita:
hola Delphius gracias por responder a mi solicitud :) pero es algo puntual lo que tengo que hacer lo del if solo se me ocurrio mira supongamos que tengo la tabla td_personas con todos sus campos y la tabla ts_auditoria con un campo de nombre audi_campo lo que tengo que hacer es copiar los registros que se ingresen en los campos de la tabla td_personas (que no siempre se ingresaran registros en todos los campo tambien puede ser que se inserten registros en uno o dos campos de esta tabla) y que esos registro se vallan a la tabla ts_auditoria EN EL CAMPO AUDI_CAMPO espero se entienda ahora mi otra consulta es que si pueden ir en una consulta dos INSERT y si se puede me podrias dar un ej porfavor espero no molestar y gracias por tu interes saludos :) |
Cita:
Ahora que leo bien, el tema del INSERT no va a funcionar. Me parece más adecuado optar por triggers, más sabiendo que se trata de llevar un proceso de auditoría. Desconozco MySQL, no sabría decir si tiene soporte de triggers. Pero me parece que es la mejor opción. Si tiene soporte (me extrañaría si no los tuviera, sabiendo que hablan tan bien de este motor) quedaría ahora analizar cuales de los 6 posibles triggers son los que se van a emplear para llevar el proceso de auditoria: BEFORE INSERT AFTER INSERT BEFORE UPDATE AFTER UPDATE BEFORE DELETE AFTER DELETE Saludos, |
Cita:
en cuanto a si soporta triggers mysql si los soporta y el triggers que he tratado de hacer es este: CREATE TRIGGER prueba AFTER INSERT ON td_persona FOR EACH ROW BEGIN INSERT INTO ts_auditoria(audi_ip,audi_fecha,audi_tabla,audi_campo,audi_valor_anterior,audi_valor_actual) VALUES('196.94.87.0',(SELECT DATE_FORMAT(now(),'%Y/%m/%d')),'Persona',1,1,1); END; entonces necesito extraer cada registro que se haga en la tabla td_persona y mostrarlos en (OJO) el CAMPO AUDI_CAMPO de la tabla ts_auditoria entonces nose como se haria si con un IF o si se puede agregar otro insert en la misma consulta espero se entienda saludos y espero no molestar :) saludos |
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, |
Cita:
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 :) |
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 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) |
| La franja horaria es GMT +2. Ahora son las 23:53:41. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi