history rows management in database

Question

As in many databases, i am designing a database that should keep record of previous versions of the rows changed in each table.

The standard solution to this problem is

Answer 1

Would tracking it based on time help you achieve the effect you are looking for on a daily basis and at the end of the business or at mid night depending on the lowest transaction volume time if you executed a procedure to move trailing data into history table then would it help ?? that way all your updates would be inserts and no locking is required as well. Regards, Andy

Answer 2

Since you are using Oracle, you could check Oracle Flashback Technology. It records changes of all changes in database, both data and structure. It also records time stamp and user name.

I didn't use it, but it looks capable.

Answer 3

I'd create two tables: one for IsLast kind of values and one for historical ones. Then I'd setup a trigger that inserts value into the historical table every time the isLast is updated.

Answer 4

If I have 1 or 2 tables of history to keep I would do it exactly as Tuinstoel has suggested. But if you had dozens of tables to do this on I would move more toward a solution described by zendar. The reason is this.

How do you answer questions like,

• What changed since yesterday when everything was fine?

• Has user SMITHG made any changes?

Those questions require a one query per table, whether it's a separate _hist table or a partition inside the table. No matter, it's some huge list of queries. If you have a central table that looks like this, then it's a piece of pie.

table_name, Column_name, PK, Before_value, After_value, User, timestamp

Inserts have only after values,

Deletes have only before values,

Update have both but only for the columns which changed.

Some variations

You can include a column for I/U/D if you prefer You can exclude column values for Inserts and just record the PK and I since the correct values are still in the table.

Since this is Oracle you could partition on table_name, so in essence you actually do have one hist "table" per real table.

You can easily answer the above questions, which I believe are, quite simply, the most often asked questions. And it handles every question you can answer with partitions or _hist tables.