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

From: <bmeltz_at_mediaone.net>
Date: 2000/07/28
Message-ID: <8ls18b$dtg$1_at_nnrp1.deja.com>#1/1


I have done it using a history table and with multiple rows in one table. It really depends upon your application. If you are just squirling away the rows as an audit trail, a separate table is fine. If you are in a data warehousing situation and this is the employee dimension, retaining all rows in a single table if often the best approach. If query performance on current records is critical and you have a lot of employees, two tables may be better. And so on....

In either case, some kind of datestamping is required. This would include the date each record was last touched and the dates the information was valid for.

If you are keeping all the rows in one table, I also include an active record flag in order to easily find the current one.

Barry

In article <8lrq66$h1p$1_at_news1.xs4all.nl>,   "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.
>
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Fri Jul 28 2000 - 00:00:00 CEST

Original text of this message