Yo use una tecnica diferente con los datos con una sola tabla, con un numero de secuencia siendo siempre 1 el mas actual, 2 el que sigue, etc.
Luego al hacer un cambio de alguna columna lo que hacia era usar un SP que actualizaba la fecha hasta = @fechaActualizacion del registro1, renumeraba los registros sumandole 1 a la secuencia y luego insertando un registro con secuencia 1 con fecha desde = @fechaActualizacion y fecha hasta '20700101'. De esta forma si queria el registro activo solo precisaba los datos clave y secuencia 1 y si queria consideraqr la historia usaba los datos clave y las fecha desde y fecha hasta. Si en lugar de buscar por clave se busca por ejemplo por una columna estado y el estado va cambiando siendo algun estado preponderante frente a otro, el diseño debe ser diferente ya que esa forma de modelado inhabilita en muchos casos el uso de indices si no accedes por clave. Saludos -- -------------------------------- Atte. Ing. Jose Mariano Alvarez SQL Total Consulting On 10/25/07, Pablo Maximo Mazzitelli <[EMAIL PROTECTED]> wrote: > > Maxi, > > > > Una consulta más sobre esta idea. Cuando decis duplicar la estructura te > referis a tener los datos en una y cuando hay un cambio en uno de los campos > del registro, mediante el trigger pasar todo el registro que ahora pasaria a > ser el viejo a la otra tabla? > > > > Gracias > > > ------------------------------ > > *De:* [email protected] [mailto:[EMAIL PROTECTED] *En nombre de *Maxi accotto > *Enviado el:* jueves, 25 de octubre de 2007 22:13 > *Para:* [EMAIL PROTECTED] > *Asunto:* [dbms] RE: [dbms] [dbms] Diseño de Base de Datos > > > > Hola, yo duplicaria la estructura de la tabla actual y mediante triggers > cada vez que hay un cambio insertaria valores en esta ultima tabla, como > campo adicional le pondria: fecha_modificacion, usuario > > > > ----------------------------------------------------------- > > Microsoft MVP en SQL Server > > Mentor asociado en SQLTotalConsulting > > Excelencia en servicios y consultoria SQLServer > > www.sqltotalconsulting.com > > ----------------------------------------------------------- > > > > *De:* [email protected] [mailto:[EMAIL PROTECTED] *En nombre de *Pablo Maximo > Mazzitelli > *Enviado el:* jueves, 25 de octubre de 2007 09:59 p.m. > *Para:* Maxi > *Asunto:* [dbms] [dbms] Diseño de Base de Datos > > > > Amigos, > > > > Estoy dando mis primeros pasos en el diseño de base de datos y me encontré > con el siguiente problema a resolver. > > Se trata de una tabla que guarda ciertos datos de clubes como ser Nombre, > Ciudad, Provincia pero que además almacena Dirección del Club, Teléfono, > etc. La intención es que la base de datos y en particular la tabla guarde > los datos actuales pero además datos históricos. Es decir, que hoy puedo > tener la dirección y teléfono del club pero también tener la posibilidad de > saber cual era la dirección y el teléfono del mismo club 2 temporadas atrás. > > > > Mi pregunta seria saber que es recomendable para armar tablas que guarden > datos históricos. La opción que manejo son crear una tabla para aquellos > datos fijos tales como el Nombre, Ciudad, Provincia y otra con aquellos > datos que sean variables entre años distintos como Dirección, teléfono y > adosarle un campo donde se establece la fecha o temporada de modificación > junto con el id de asociación del club correspondiente. > > > > Alguien puede decirme si esto es correcto o existe alguna idea mejor?. Es > importante aclarar que mi idea es usar esta base de datos en una aplicación > que haga alta, baja y modificación pero que permita ver valores de años > anteriores. > > > > Desde ya les agradezco la ayuda de antemano. > > >
