Desarrollar base de datos con históricos (Auditorías)

03/09/2004 - 11:57 por Lara | Informe spam
Hola grupo!

He diseñado una base de datos para una aplicación que gestiona seguros de
coches. Cada vez que modifico un registro, actualizo un campo llamado
FechaModificación para saber cuándo fué la última vez que modifiqué dicho
registro. Todas las tablas de la base de datos tienen este campo
FechaModificación.

El problema viene porque necesito "rediseñar" la base de datos para que me
almacene todas las modificaciones que se van a realizar sobre los datos, no
me basta con conocer la FechaModificacion, sino que necesito conocer los
datos que había en cada momento...de tal manera, que por ejemplo, un usuario
de la aplicación pueda visualizar los datos de una póliza de seguros hace 2,
3, 4 meses...

Estoy pensando cómo diseñar la base de datos para que me guarde toda esta
información y que mis datos mantengan la integridad.

Una forma podría ser duplicando cada tabla. Tabla1-Tabla1_Historico;
Tabla2->Tabla2_Historico. Y cada vez que modifique un registro, modificar
e insertar datos en todas las tablas del histórico que tengan relación con
ésta.

Otra forma podría ser, relacionar los datos de una tabla y los datos
modificados de esa misma tabla, mediante un árbol, en el que hay un registro
"padre" y varios registros "hijos" que dependen de él y que contendrá el
registro modificado con su FechaModificación.
Os pongo un ejemplo para ver si se entiende mejor:

Tabla: TipoPoliza

IdTipoPoliza IdPadre Descripcion FechaModificacion
1 0 Poliza1 01/09/2004
2 0 Poliza2 01/09/2004
3 1 Poliza1.1 05/09/2004
4 1 Poliza1.2 02/10/2004
..

En el ejemplo, se ve que la "Poliza1" es modificada dos veces, y como el
IdTipoPoliza es el número 1, en el IdPadre de Poliza1.1 y Poliza1.2 aparace
el 1.

De esta forma, y filtrando por la FechaModificacion, siempre puedo saber
cómo se denominaba el TipoPoliza en diferentes fechas..

Añado al ejemplo una tabla Poliza que va a tener un IdTipoPoliza

Tabla: Poliza

IdPoliza IdPadre Descripcion IdTipoPoliza
FechaModificacion
1 0 Descripcion Poliza1 1
01/09/2004


En cuanto modifique el registro 1 de la tabla TipoPoliza, debería modificar
también la tabla Póliza, para guardar ese cambio, ya que la Poliza con
identificador 1, tiene como TipoPoliza el identificador 1, y como el
05/09/2004 ha sido modificado su descripción de Poliza1 a Poliza1.1, lo que
yo añadiría en la tabla Poliza sería lo siguiente:

Tabla: Poliza

IdPoliza IdPadre Descripcion IdTipoPoliza
FechaModificacion
1 0 Descripcion Poliza1 1
01/09/2004
2 1 Descripcion Poliza1 3
05/09/2004


Espero que se entienda en qué consiste esta segunda forma de guardar un
histórico de cambios..

Lo que me gustaría es que me dierais vuestra opinión, sobre si alguna de
esta formas es óptima, o bien, que me enviárais algún link con información
sobre este tema.

Muchísimas gracias! Siento no tener mucho tiempo para explicar mejor el
problema

Saludos!
Lara

Preguntas similare

Leer las respuestas

#1 qwalgrande
03/09/2004 - 12:23 | Informe spam
Hola.

Te voy a dar mi opinión basada en una experiencia parecida que se me
presentó no hace mucho.

La primera de las opciones es más fácil de implementar y sobre todo más
fácil de explotar. Las estructuras en árbol, a la larga, complican la
existencia sobre manera, sobre todo para realizar consultas. Almacenar
cambios en histórico puedes hacerlo incluso con triggers, aunque yo lo haría
con procedimientos almacenados, es decir, aprovecharía los procedimientos
almacenados de alta, borrado y modificación para incluir la grabación en el
histórico. También entiendo que si desde el inicio no optaste por el uso de
procedimientos almacenados, ahora quizá te sea mucho más cómodo usar
triggers. Plantéatelo de todos modos.

Otra cosa que facilita mucho la primera opción (además de permitirte
independizar los datos que valen de los que sólo son histórico) es el
necesario mantenimiento que todo histórico precisa. Debes plantearte que cada
cierto tiempo, esas tablas de log hay que aligerarlas, llevarlas a otra bd,
hacer backup y borrar, en fin, lo que tú veas.

qwalgrande.
Respuesta Responder a este mensaje
#2 Lara
03/09/2004 - 12:45 | Informe spam
A mí también me parece más sencillo crear una tabla_histórico por cada
tabla, y utilizar procedimientos almacenados. Lo que ocurre es que hay gente
del equipo de proyecto que es muy reacia a su utilización, prefiere utilizar
métodos para estas operaciones.

En este artículo de Microsoft se habla del tema de los triggers para generar
una Auditoría:
http://www.microsoft.com/spanish/ms...art168.asp
pero no estoy segura que todo lo pueda hacer con triggers, pienso que es más
seguro utilizar procedimientos y controlar yo las operaciones.

El tema del mantenimiento del histórico, también se ha planteado, que cada
año, seguramente haya que "limpiar" datos y volver a empezar el histórico.
La verdad, que todo lo que me cuentas me anima más a seguir tu experiencia.
Ahora tengo que "luchar" con el equipo para convencerles...
Muchas gracias!
Y si alguien tienen alguna opinión más es de agradecer!




"qwalgrande" <qwalgrande*nospam*@yahoo.es> escribió en el mensaje
news:
Hola.

Te voy a dar mi opinión basada en una experiencia parecida que se me
presentó no hace mucho.

La primera de las opciones es más fácil de implementar y sobre todo más
fácil de explotar. Las estructuras en árbol, a la larga, complican la
existencia sobre manera, sobre todo para realizar consultas. Almacenar
cambios en histórico puedes hacerlo incluso con triggers, aunque yo lo


haría
con procedimientos almacenados, es decir, aprovecharía los procedimientos
almacenados de alta, borrado y modificación para incluir la grabación en


el
histórico. También entiendo que si desde el inicio no optaste por el uso


de
procedimientos almacenados, ahora quizá te sea mucho más cómodo usar
triggers. Plantéatelo de todos modos.

Otra cosa que facilita mucho la primera opción (además de permitirte
independizar los datos que valen de los que sólo son histórico) es el
necesario mantenimiento que todo histórico precisa. Debes plantearte que


cada
cierto tiempo, esas tablas de log hay que aligerarlas, llevarlas a otra


bd,
hacer backup y borrar, en fin, lo que tú veas.

qwalgrande.
Respuesta Responder a este mensaje
#3 Lara
03/09/2004 - 13:21 | Informe spam
Hola de nuevo!

Partiendo que el histórico lo quiero realizar creando una tabla_histórico
por cada tabla, me surge el siguiente problema:

Tenemos una tabla TipoPoliza y otra Poliza. La relación entre ambas tablas
es que cada póliza es de un tipo.

Hacemos los siguientes pasos:

1.- Insertamos un tipo de póliza, tanto en la tabla TipoPoliza como en la
tabla TipoPoliza_Historico

Tabla TipoPoliza:
IdTipoPoliza Descripcion FechaModificacion
1 TipoPoliza1 01/01/2004

Tabla TipoPoliza_Historico:
IdTipoPoliza Descripcion FechaModificacion
1 TipoPoliza1 01/01/2004


2.- Insertamos una póliza, con un determinado tipo de póliza, tanto en la
tabla Poliza como en Poliza_Historico.

Tabla Poliza:
IdPoliza IdTipoPoliza Descripcion FechaModificacion
1 1 Poliza1 01/01/2004

Tabla Poliza_Historico:
IdPoliza_Historico IdTipoPoliza IdPoliza Descripcion FechaModificacion
1 1 1 Poliza1
01/01/2004


3.- Modificamos la descripción de un tipo de póliza (modificando la tabla
TipoPoliza), y para guardar este cambio insertamos un nuevo registro en
TipoPoliza_Historico.

Tabla TipoPoliza:
IdTipoPoliza Descripcion FechaModificacion
1 TipoPoliza1Modificada 25/01/2004

Tabla TipoPoliza_Historico:
IdTipoPoliza Descripcion FechaModificacion
1 TipoPoliza1 01/01/2004
1 TipoPoliza1Modificada 25/01/2004

4.- Recordemos que nuestra Póliza estaba asignada a un tipo de póliza, que
justamente es el tipo de póliza que acabamos de modificar. Qué ocurre? que
estamos perdiendo la relación de la Póliza con su tipo de póliza inicial.
Cómo podemos mantener en el histórico esta relación? Qué pasos debemos
seguir?


Muchas gracias!!





"qwalgrande" <qwalgrande*nospam*@yahoo.es> escribió en el mensaje
news:
Hola.

Te voy a dar mi opinión basada en una experiencia parecida que se me
presentó no hace mucho.

La primera de las opciones es más fácil de implementar y sobre todo más
fácil de explotar. Las estructuras en árbol, a la larga, complican la
existencia sobre manera, sobre todo para realizar consultas. Almacenar
cambios en histórico puedes hacerlo incluso con triggers, aunque yo lo


haría
con procedimientos almacenados, es decir, aprovecharía los procedimientos
almacenados de alta, borrado y modificación para incluir la grabación en


el
histórico. También entiendo que si desde el inicio no optaste por el uso


de
procedimientos almacenados, ahora quizá te sea mucho más cómodo usar
triggers. Plantéatelo de todos modos.

Otra cosa que facilita mucho la primera opción (además de permitirte
independizar los datos que valen de los que sólo son histórico) es el
necesario mantenimiento que todo histórico precisa. Debes plantearte que


cada
cierto tiempo, esas tablas de log hay que aligerarlas, llevarlas a otra


bd,
hacer backup y borrar, en fin, lo que tú veas.

qwalgrande.
Respuesta Responder a este mensaje
#4 Salvador Ramos
03/09/2004 - 13:45 | Informe spam
Hola:

Personalmente también es la de las tablas históricas la solución que más me
gusta. Lo que no coincido es en cuanto a la implementación, yo la haría
mediante triggers. Además sería bastante sencilla que sería cuestión de
almacenar el contenido de la "tabla virtual" deleted que tienes disponible
cuando se dispara el trigger. Además tienes la ventaja que si alguien
modifica cualquier dato desde fuera de tu aplicación, también se registraría
esta información en tu histórico.

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net
¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"Lara" escribió en el mensaje
news:
A mí también me parece más sencillo crear una tabla_histórico por cada
tabla, y utilizar procedimientos almacenados. Lo que ocurre es que hay


gente
del equipo de proyecto que es muy reacia a su utilización, prefiere


utilizar
métodos para estas operaciones.

En este artículo de Microsoft se habla del tema de los triggers para


generar
una Auditoría:
http://www.microsoft.com/spanish/ms...art168.asp
pero no estoy segura que todo lo pueda hacer con triggers, pienso que es


más
seguro utilizar procedimientos y controlar yo las operaciones.

El tema del mantenimiento del histórico, también se ha planteado, que cada
año, seguramente haya que "limpiar" datos y volver a empezar el histórico.
La verdad, que todo lo que me cuentas me anima más a seguir tu


experiencia.
Ahora tengo que "luchar" con el equipo para convencerles...
Muchas gracias!
Y si alguien tienen alguna opinión más es de agradecer!




"qwalgrande" <qwalgrande*nospam*@yahoo.es> escribió en el mensaje
news:
> Hola.
>
> Te voy a dar mi opinión basada en una experiencia parecida que se me
> presentó no hace mucho.
>
> La primera de las opciones es más fácil de implementar y sobre todo más
> fácil de explotar. Las estructuras en árbol, a la larga, complican la
> existencia sobre manera, sobre todo para realizar consultas. Almacenar
> cambios en histórico puedes hacerlo incluso con triggers, aunque yo lo
haría
> con procedimientos almacenados, es decir, aprovecharía los


procedimientos
> almacenados de alta, borrado y modificación para incluir la grabación en
el
> histórico. También entiendo que si desde el inicio no optaste por el uso
de
> procedimientos almacenados, ahora quizá te sea mucho más cómodo usar
> triggers. Plantéatelo de todos modos.
>
> Otra cosa que facilita mucho la primera opción (además de permitirte
> independizar los datos que valen de los que sólo son histórico) es el
> necesario mantenimiento que todo histórico precisa. Debes plantearte que
cada
> cierto tiempo, esas tablas de log hay que aligerarlas, llevarlas a otra
bd,
> hacer backup y borrar, en fin, lo que tú veas.
>
> qwalgrande.


Respuesta Responder a este mensaje
#5 Maxi
03/09/2004 - 14:27 | Informe spam
Hola, coincido m100% contigo, lo mejor es usar TR para esto :-)


Salu2
Maxi
Buenos Aires - Argentina
Desarrollador Microsoft 3 Estrellas .NET
Nunca consideres el estudio como una obligación sino como
una oportunidad para penetrar en el bello y maravillosos
mundo del saber.
- Albert Einstein



"Salvador Ramos" escribió en el
mensaje news:
Hola:

Personalmente también es la de las tablas históricas la solución que más


me
gusta. Lo que no coincido es en cuanto a la implementación, yo la haría
mediante triggers. Además sería bastante sencilla que sería cuestión de
almacenar el contenido de la "tabla virtual" deleted que tienes disponible
cuando se dispara el trigger. Además tienes la ventaja que si alguien
modifica cualquier dato desde fuera de tu aplicación, también se


registraría
esta información en tu histórico.

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net
¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"Lara" escribió en el mensaje
news:
> A mí también me parece más sencillo crear una tabla_histórico por cada
> tabla, y utilizar procedimientos almacenados. Lo que ocurre es que hay
gente
> del equipo de proyecto que es muy reacia a su utilización, prefiere
utilizar
> métodos para estas operaciones.
>
> En este artículo de Microsoft se habla del tema de los triggers para
generar
> una Auditoría:
>


http://www.microsoft.com/spanish/ms...art168.asp
> pero no estoy segura que todo lo pueda hacer con triggers, pienso que es
más
> seguro utilizar procedimientos y controlar yo las operaciones.
>
> El tema del mantenimiento del histórico, también se ha planteado, que


cada
> año, seguramente haya que "limpiar" datos y volver a empezar el


histórico.
> La verdad, que todo lo que me cuentas me anima más a seguir tu
experiencia.
> Ahora tengo que "luchar" con el equipo para convencerles...
> Muchas gracias!
> Y si alguien tienen alguna opinión más es de agradecer!
>
>
>
>
> "qwalgrande" <qwalgrande*nospam*@yahoo.es> escribió en el mensaje
> news:
> > Hola.
> >
> > Te voy a dar mi opinión basada en una experiencia parecida que se me
> > presentó no hace mucho.
> >
> > La primera de las opciones es más fácil de implementar y sobre todo


más
> > fácil de explotar. Las estructuras en árbol, a la larga, complican la
> > existencia sobre manera, sobre todo para realizar consultas. Almacenar
> > cambios en histórico puedes hacerlo incluso con triggers, aunque yo lo
> haría
> > con procedimientos almacenados, es decir, aprovecharía los
procedimientos
> > almacenados de alta, borrado y modificación para incluir la grabación


en
> el
> > histórico. También entiendo que si desde el inicio no optaste por el


uso
> de
> > procedimientos almacenados, ahora quizá te sea mucho más cómodo usar
> > triggers. Plantéatelo de todos modos.
> >
> > Otra cosa que facilita mucho la primera opción (además de permitirte
> > independizar los datos que valen de los que sólo son histórico) es el
> > necesario mantenimiento que todo histórico precisa. Debes plantearte


que
> cada
> > cierto tiempo, esas tablas de log hay que aligerarlas, llevarlas a


otra
> bd,
> > hacer backup y borrar, en fin, lo que tú veas.
> >
> > qwalgrande.
>
>







Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.748 / Virus Database: 500 - Release Date: 01/09/2004
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente Respuesta Tengo una respuesta
Search Busqueda sugerida