Best practices for creating and querying a history table?

Question

Suppose I have a table of name-value pairs, and I want to keep track of changes to them so that I can query the value of any pair at any point in time.
A direct approach would be to use a schema like this:
CREATE TABLE NAME_VALUE_HISTORY (
  NAME      VARCHAR2(...),
  VALUE     VARCHAR2(...),
  MODIFIED DATE
);When a name-value pair is updated, a new row is added to this table with the date of the change.
To determine the value associated with a name at a particular point in time, one uses a query like:
  SELECT * FROM NAME_VALUE_HISTORY
  WHERE NAME = :name
    AND MODIFIED IN (SELECT MAX(MODIFIED)
                    FROM NAME_VALUE_HISTORY
                    WHERE NAME = :name AND MODIFIED <= :time)My question is: is there a better way to accomplish this? What indexes/hints would you recommend?
What about a two-table approach like this one? http://pratchev.blogspot.com/2007/05/keeping-history-data-in-sql-server.html
Edited by: user10936714 on Aug 9, 2012 8:35 AM

Answer 1

user10936714 wrote:
There is one advantage... recording the change of a value is just one insert, and it is also atomic without the use of transactions.At the risk of being dumb, why is that an advantage? Oracle always and everywhere uses transactions so it's not like you're avoiding some overhead by not using transactions.
If, for instance, the performance of reading the value of a name at a point in time is not important, then you can get by with just using one table - the history table.If you're not overly concerned with the performance implications of having the current data and the history data in the same table, rather than rolling your own solution, I'd be strongly tempted to use Workspace Manager to let Oracle keep track of the changes.
You can create a table, enable versioning, and do whatever DML operations you'd like
SQL> create table address(
  2    address_id number primary key,
  3    address    varchar2(100)
  4  );
Table created.
SQL> exec dbms_wm.enableVersioning( 'ADDRESS', 'VIEW_WO_OVERWRITE' );
PL/SQL procedure successfully completed.
SQL> insert into address values( 1, 'First Address' );
1 row created.
SQL> commit;
Commit complete.
SQL> update address
  2     set address = 'Second Address'
  3   where address_id = 1;
1 row updated.
SQL> commit;
Commit complete.Then you can either query the history view
SQL> ed
Wrote file afiedt.buf
  1  select address_id, address, wm_createtime
  2*   from address_hist
SQL> /
ADDRESS_ID ADDRESS                        WM_CREATETIME
         1 First Address                  09-AUG-12 01.48.58.566000 PM -04:00
         1 Second Address                 09-AUG-12 01.49.17.259000 PM -04:00Or, even cooler, you can go back to an arbitrary point in time, run a query, and see the historical information. I can go back to a point between the time that I committed the first change and the second change, query the ADDRESS view, and see the old data. This is invaluable if you want to take existing queries and/or reports and run them as of certain dates in the past when you're trying to debug a problem.
SQL> select *
  2    from address;
ADDRESS_ID ADDRESS
         1 First AddressYou can also do things like set savepoints which are basically named points in time that you can go back to. That lets you do things like create a savepoint for the data as soon as month-end processing is completed so you can easily go back to "July Month End" without needing to figure out exactly what time that occurred. And you can have multiple workspaces so different users can be working on completely different sets of changes simultaneously without interfering with each other. This was actually why Workspace Manager was originally created-- to allow users manipulating spatial data to have extremely long-running transactions that could span days or months-- and to be able to switch back and forth between the current live data and the data in each of these long-running scenarios.
Justin