Re: Triggers para actualizar varias tablas por campos se podria hacer mas optimos que problemas podria haber

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 (<hivs77(at)gmail(dot)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 (
> jvenegasperu(at)gmail(dot)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