Re: diseño 'óptimo' de bitácoras (logs)

El 18/09/07, Marco Antonio Frias Butrón <marcoantoniofrias(at)gmail(dot)com> escribió:
> Planteo porque pienso que muchos en algún momento hemos tenido que
> diseñar bitácoras (logs) para las entidades de nuestro modelo.

Si, yo también tuve y tengo ese problema je!

> Ahora
> bien, en mi caso yo diseñe una estructura bastante parecida a un
> ejemplo que viene en el manual:
>
> http://www.postgresql.org/docs/8.2/static/plpgsql-trigger.html#PLPGSQL-TRIGGER-AUDIT-EXAMPLE
>

>
> La duda puntual que tengo es si vosotros tienen una mejor solución
> para este tema...
>

Bueno, te puedo contar como medio solucione, pero no creo que sea una
mejor solución que la tuya, por cuestiones de tiempo de desarrollo
tuve que dejarlo así:

(Para entrar en contexto: soy programador jsp con postgresql)

Nosotros solamente utilizamos un usuario para conectarse a la bd,
por lo que ese ejemplo no pude implementar correctamente, no encontré
la forma de pasarle el usuario interno de la aplicacion ya que el
trigger usa el usuario interno de postgresql.

Entonces un compañero me sugirió e hice lo siguiente:
Cree una tabla para registrar las operaciones sql que se ejecutan en
el programa que realizo.

REATE TABLE auditoria_sql
(
asql_id serial NOT NULL,
paginas_pag_id integer NOT NULL,
usuarios_usu_id integer NOT NULL,
asql_fecha_hora timestamp without time zone NOT NULL DEFAULT now(),
asql_sql character varying(30000) NOT NULL,
asql_ip character varying(15) NOT NULL,
CONSTRAINT auditoria_sql_pkey PRIMARY KEY (asql_id),
CONSTRAINT "$1" FOREIGN KEY (usuarios_usu_id)
REFERENCES usuarios (usu_id) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT,
CONSTRAINT "$2" FOREIGN KEY (paginas_pag_id)
REFERENCES paginas (pag_id) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT
)

Entonces despues de cada insert, update o delete en mis paginas le
agregue una "accion de auditoria" que hace un insert a esta tabla con
los datos.

Solamente le encuentro el defecto de que no puede guardar los datos de
los registros borrados, pero me puede decir quien lo borro, ya que
queda registrado el delete que realizo.

En mi caso específico yo solamente tengo acciones de delete en las
entidades fuertes y en las entidades maestro / detalle tengo acciones
de anular que hacen un update a un campo-bandera en las tablas.

Hay varias cuestiones a sopesar cuando se trata de agregar acciones de
auditoria:
* Si necesitas maxima seguridad de poder restaurar un registro que fue
borrado, no hay mas remedio que la redundancia: debes tener una tabla
identica (con los mismos campos) a la auditada con los campos para
auditoria y hacer la auditoria por triggers.

Por supuesto deberas crear usuarios en tu bd limitados para cada
seccion de tu BD (Todo esto agrega mucha complejidad)

* Depende realmente de la complejidad de tu bd, si es para una PyME es
diferente a si es para una Multinacional o si es una aplicación para
una entidad financiera.

Mi solucion tiene varios defectos: si alguien hace algun cambio
directamente en la BD (sin pasar por mi software) no sera registrado,
generándose inconsistencia.

Pero para que esto ocurra otras personas deberán tener acceso a la
cuenta de Administrador de la BD.

Y esto es un punto a favor de tu solucion.

Espero haberte ayudado, ah! y disculpen la longitud del mail je!.
--
§~^Calabaza^~§ from Villa Elisa, Paraguay