Visit my Blog for the original post: Design a Table to Keep Historical Changes in Database
Back to months ago, I encountered a classical problem: ...
For further actions, you may consider blocking this person and/or reporting abuse
I think History Table is the best and most popular way to do this. Audit table has 2 huge drawbacks:
I want to add more that for an ordinary system where real-time data is not crucial, table history can be recorded periodically using a cron job (aka. scheduled task), record history per transaction is usually costly without much benefits.
how do we then insert records into the original table and history table at same time? do we run insert query to insert into the 2 tables at same time? since you said using foreign keys is a bad idea...can you please share details of how to approach this?
Hi - Very good post on Auditing Mysql.
Question:
Can you actually show an example of how would you write a trigger for 3rd approach which is the audit table. I have implemented this but the trigger query that I use is very costly. So wanted to understand how would you implement column level changes to be recorded in audit table
Hi, thanks a lot!
I used C# and entity framework and the audit records are generated at code level. So unfortunately I didn't write a trigger for that.
What if your entity is stored serialized in a XML column? What strategy you think is best for that case?
Would be interesting having a History table storing the previous serialized value? What if we use a diff algorithm and store diff changes to reduce redundancy? In our case, when you get the history of an entity, you get all changes (maybe 10-20 changes records)
A history table sounds like a simple solution to me. But I still see a few cons:
If I have a lot of tables, I also need a lot of historical counterparts.
And if the database is still in development or fields change, then the fields of the historical table must also be adjusted and scripts must be adapted.
So I now had the following idea for a single historical table:
ID, TableName, RecordID, JSON (with dataset dump from Table).
Would this solution have any disadvantages?
Great post this was very helpful!
To clarify, if I want to track the history for N tables, it sounds like the history pattern would require N duplicate tables, but the auditor pattern would only require 1. Is that correct?
Also, what are your thoughts on having a history column? Here you add a "history" column to your table with a JSON blob of that history for that row. We don't expect many changes to the data, so we don't expect the blob size to be a problem
When I saw this I thought it will solve the N tables problem. But investigating further this is what i found...
The history column will only point to one history record, but to get a full history of the a single record we will need to recursively call each history record right? That could become very complicated in comparison to having different history tables.
How to manage history table if I want to delete a record from the main table?
Thanks
One option is to use a soft-delete i.e. set IsEnabled = false
how do we then insert records into the original table and history table at same time? do we run insert query to insert into the 2 tables at same time?
You can run two distinctive inserts within the same transaction scope.