Jim,

I forgot one...

>The design problem that I ahve with the "stacked" approach you suggest has nothing to do with normalization, it has to do with another relational design objective altogether and that is each entity should have a single discrete thing about which it records information. With the stacked approach a single entity is trying to be both current data and historical data at the same time. While with a second history table one is current and the other is historical.
>
>Also if you carry the design requirement a little further and discover that there are more than one table that needs to track history of changes, you then need to adapt all the tables that need it for stacked tracking, while with my approach there is still only one history table that simply has to be used by mroe than one other table. Also if the data to be tracked is only poart of the full record, using the same table uses space for all fields instead of just those that require tracking, while my approach is able to be adpated to handle the decision of which field s to track.

The problem with shadowing is also that it is harder to handle changes in the future. Therefore you would have three tables:
- the past
- the curent
- the future

Especially when handeling the future there are some problems to overwin.

Walter,