Re: [Q] Most logical way to keep history ?

I agree that this is a good book for issues you state but I don't think it is hard to read because of the depth; it is hard to read because it is poorly presented. I sat in Professor Snodgrass's course and he is smart and his journal articles are excellent, but he didn't make the transition from academician to teacher very well. If you can follow the code, the ideas are right on.

Martin Fowler wrote:

> History is a very complicated issue, particularly so with SQL
> databases. My best advice is to get the book by Snodgrass
> <http://www.amazon.com/exec/obidos/ASIN/1558604367>. Due to its depth
> you may find it hard going, but I find he realistically discusses many
> of the painful issues that I've run into with temporal problems in
> business systems.
>
> Martin
>
> On Fri, 28 Jul 2000 13:18:19 +0200, "Jerold"
> <dlareg_spamfilter__at_cryogen.com> wrote:
>
> >Hi,
> >
> >What is the most logical solution, or 'best' solution according to
> >database-theory to keep the history of an object (row) in a table.
> >
> >ie:
> >Employee Table
> >Fields: id, Name, Adress, Age
> >
> >If one changes the Name the old information should be stored somewhere in
> >the database so that the change can be looked up.
> >(so a history of changes to a certain employee is built up)
> >
> >Should I make a separate table called 'old employee'. Or use a parent-child
> >kind of relation ship within the Employee Table like:
> >Employee: id, Name, Adress, Age, Parent. where "parent" points to its
> >(newer) parent. ?
> >
> >Thanks!
> >
> >Jerold.
> >
> >

David Olsen Received on Mon Jul 31 2000 - 00:00:00 CEST