Re: Temporal Data (long)

In article <1996Aug7.232510.15823_at_giant> dwyche_at_giant.intranet.com (A little left of plumb) writes:
>
> Temporal Data
>
>My apologies in advance for the lack of brevity. I really tried hard for
>clarity instead...
>
>We have an Oracle-based application that warehouses data extracted from our
>main non-relational OLTP system for both reporting and long-term archiving
>purposes. Unfortunately all tables need to contain data that changes with
>time. In order to achieve this we included an extra key-field for each
>table. That is, a logical table structure that looked like:
>
> K1, K2, K3, D1, D2, D3, D4, ...
>
>where Kn are key fields and Dn are data fields, will be stored instead
>in the following structure:
>
> K1, K2, K3, KT, D1, D2, D3, D4, ...
>
>where the new KT field is a timestamp that indicates the date/time that
>the information in the row became effective.
>
>The difficulty with this approach is in the extraction of the 'correct'
>information for reporting purposes. Our users want current information 99%
>of the time.

How about simply maintaining a current table. Whenever a row becomes current, copy or update to the current table. This would add a little complexity and denormalization to the warehouse, with the benefit that users could do simple queries. If it's 99% of the queries, it's worth it. I hope that other 1% justifies having a warehouse.

-- 
Joel Garry               joelga_at_rossinc.com               Compuserve 70661,1534
These are my opinions, not necessarily those of Ross Systems, Inc.   <> <>
%DCL-W-SOFTONEDGEDONTPUSH, Software On Edge - Don't Push.            \ V /
panic: ifree: freeing free inodes...                                   O