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

From: Thomas Jørgensen <>
Date: 2000/08/02
Message-ID: <>#1/1


First I must agree with you all, history is a complex task to manage in SQL. I am representing a company called TimeChain Technology - <> - where the main focus is to assist users in managing temporal data.

To do so we are currently developing a temporal tool called tDeveloper, which we expect to release a beta copy of in the middle of august.

At the moment features include:

  • Convertion of non-temporal tables into temporal ones
  • Visual management and code generation for temporal constraints (Primary key, Foreign key, Uniqueness)
  • Optimization (Indexing, Coalescing)

If any of you are interessted in more information feel free to mail any questions. Furthermore, if you wish to be notified when we are releasing our beta version, please let me know(we will add a mailinglist in the near future)

Best regards
Thomas Jørgensen

Martin Fowler wrote:
> History is a very complicated issue, particularly so with SQL
> databases. My best advice is to get the book by Snodgrass
> <>. 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"
> <> 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.
> >
> >
Received on Wed Aug 02 2000 - 00:00:00 CEST

Original text of this message