Log Buffer #170

This method is not mutually exclusive with an audit trail. I don’t think it is usually worth to save a diff of the change. The alternative is save a copy of each record, which is what this revisioning system does. The audit trail table can than simply look like

CREATE TABLE `audit_trail` (
  `table` varchar(255) NOT NULL,
  `id` int(10) UNSIGNED NOT NULL,
  `revision` bigint(20) UNSIGNED DEFAULT NULL,
  `user_id` int(10) UNSIGNED DEFAULT NULL,
  `timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  KEY `id` (`table`,`id`,`revision`),
  KEY `revision` (`table`,`revision`),
  KEY `user_id` (`user_id`)
  KEY `timestamp` (`timestamp`),
)

This could replace the history tables. Do note that your forced in using surrogate keys for all revisioned tables.

You should still make a periodic backups, even when using this method. Those backups are basically snapshots.

As you already state in your article, versioned objects highly complicate the logic of the application layer. I don’t like that, since that is usually the place that is already complex, shouldn’t be over abstracted and where most bugs appear.

It is also less then optimal when trying to analyze what kind of changes happen on the database.

Another question often asked is: what happend at a certain time in the system, which probably would be better answered by some kind of audit trail.

So before you implement an approach like this, I’d recommend thinking about some different options.

I wrote a german article about this some time ago: http://blog.schauderhaft.de/2008/09/14/versionierte-vs-historisierte-objekte/

I used to work with similar solution on Postgres and it was really working well.

The coolest thing we had in our system was that versioning and history were completly separated from application and kept in db layer. The only thing application could use is to manipulate the CURRENT_VIEW_TIME value. Then views on all the tables would pick rows from real table or from history table so that you were transparently accessing data as it was exactly on CURRENT_VIEW_TIME.

We had begin and end time in every history row to make this calculation easier.

Suprisyngly it was working well and not really so slow either. It was the collest thing ever! :- )

But i agree once you add triggers and lots of them forget about replication … well maybe row-level-replication would work for you.

Very nice article! thanks

Baron: I agree that you have to be careful with using triggers to alter data. Keep it simple and don’t try to develop half your application in triggers and stored procedures.

However, with this method it is very unlikely to mess up your data (in the original table), since:
1. A trigger on the original table, can’t update that same table. You can therefore only mess up the data you’re inserting/updating.
2. The data in the revisioning table is a copy. If an error would mess up that table, you can remove it and only use the history, not the current data.
3. You should still run a nightly backup and store that off-disk. The data would still be lost I the disk crash or something else terrible would happen. There are no alternatives to making backups, not this, not replication, not RAID, not anything.
4. Programming error can happen anywhere, here as well as in the application code.

If you see something potentially unsafe about the above code, please let me know what that is.