Hellmuth Buen dia gracias por los enlaces de hecho tengo implementado lo que indica el primer link con tablas de auditoria y todo funciona hasta ahora perfecto.
Mi consulta va en el sentido de que tengo un trigger que se usa en diferentes tablas mi pregunta iba apelando a su experiencia que tan buen diseño es manejarlo asi o que problemas podria tener en el futuro por ejemplo ademas de los usuarios y fechas tengo tambien un trigger que calcula el area otro que calcula el perimetro un trigger individual por cada campo luego aplico estos triggers por ejemplo a las tablas como: manzanas lotes lagunas distritos urbanizaciones juntas vecinales y un largo etc todas tienen area y perimetro asi que aplico el mismo trigger a todas las tablas donde en todas existe un campo area y perimetro esa es mi consulta si este diseño te parece correcto o que problemas podrian ocurrir de emplear el mismo trigger en diferentes tablas ya que tengo como 200 tablas apuntando al mismo codigo de trigger y uso tambien un trigger individual por cada campo porque por ejemplo algunas tablas tienen areas otras perimetro otras longitud entonces de acuerdo a la tabla aplico los triggers que necesito y nombro a los campos en las tablas con los mismos nombres. Esto viene funcionando de maravilla y quiero ampliar esta manera de trabajo haciendolo no solo para el calculo individual de un campo sino para efectuar calculos comunes pero que involucran otras tablas por ejemplo el metrado de red de agua por distrito junta vecinal o urbanizacion usare una tabla distinta como parametro de acuerdo a la solicitud del usuario entonces como ya no es tan simple como trabajar con el mismo campo de la base de datos mi pregunta es si alguien tiene un diseño similar y viene trabajando asi que problemas podria haber o que se podria mejorar. saludos Jose El mar., 4 jun. 2019 a las 10:49, Hellmuth Vargas (<hiv...@gmail.com>) escribió: > Hola Lista > > En el siguiente link hay una versión que permite una gestión > estandarizada: > https://wiki.postgresql.org/wiki/Audit_trigger > > En este, estrategias disponibles para auditoria: > https://severalnines.com/blog/postgresql-audit-logging-best-practices > > > > > El dom., 2 de jun. de 2019 a la(s) 21:09, Jose Mercedes Venegas Acevedo ( > jvenegasp...@gmail.com) escribió: > >> Estimados >> Buen dia a todos >> >> Desde hace algun tiempo vengo manejando triggers para manejar el >> seguimiento de las actividades de los usuarios en una tabla >> a todas mis tablas siempre le agrego cuatro campos: >> usuario -- El usuario que crea el registro >> usuario_update -- El usuario que hizo la ultima modificacion al registro >> fregistro -- Timestamp del momento en que se creo el registro >> fupdate -- Timestamp del momento en que se produjo la ultima modificacion. >> >> El hecho es que tengo un trigger individual por cada campo y luego lo >> aplico a cada tabla tengo como 200 tablas y toda usan estos mismos 4 >> triggers como por ejemplo aqui lineas mas abajo pongo el trigger para el >> usuario que actualiza. >> >> Mi pregunta es que les parece esta manera de usar los triggers ahora >> estoy pensando hacer esto mismo con otros campos comunes que estan >> apareciendo en mis tablas y quisiera su opinion de alguna idea para mejorar >> o que problemas podria tener al usar el mismo trigger en todas las tablas o >> quiza juntar todos los campos comunes en un solo trigger creen que esto es >> correcto? seria mejor tener un trigger distinto para cada tabla? que >> problemas creen que se podrian presentar bueno vengo trabajando de esta >> forma ya hace como dos años pero mis base de datos es solo para unos 50 >> usuarios aprox que estan modificando y consultando una BD con postgis y >> hasta ahora ningun problema pero la BD y usuarios estan creciendo asi que >> decidi preguntar por aqui haber que ideas me podrian dar >> >> CREATE OR REPLACE FUNCTION public.usuario_upd() >> RETURNS trigger AS >> $BODY$ >> DECLARE >> >> BEGIN >> NEW.usuario_update := "current_user"(); >> RETURN NEW; >> END >> $BODY$ >> LANGUAGE plpgsql VOLATILE STRICT >> COST 50; >> ALTER FUNCTION public.usuario_upd() >> OWNER TO postgres; >> >> drop trigger usuario_colector_upd; >> >> CREATE TRIGGER usuario_colector_upd >> BEFORE UPDATE >> ON public.al_colector_geo >> FOR EACH ROW >> EXECUTE PROCEDURE public.usuario_upd(); >> >> -- >> José Mercedes Venegas Acevedo >> cel Mov RPC 964185205 >> >> >> > > -- > Cordialmente, > > Ing. Hellmuth I. Vargas S. > Esp. Telemática y Negocios por Internet > Oracle Database 10g Administrator Certified Associate > EnterpriseDB Certified PostgreSQL 9.3 Associate > > -- José Mercedes Venegas Acevedo cel Mov RPC 964185205
