Thanks for commenting

MySQL (and other RDBMS) don’t support versioning natively, which is a pain. This means that you have to do it yourself.

If we look at the most basic versioning system, it saves a copy of a file (or in this case record) whenever the file is changed. Since there can only be one version of a file on a (standard) file system, a copy needs to be saved elsewhere. We’re doing the same with MySQL (so no shoe horning here).

Using LVM is a great way to get a snapshot of the complete database at a certain time. However, this is very much a sysadmin tool. You can’t (easily) use it to show a user (the manager of a company for instance) the history of a record and allow him to roll back changes.

I strongly consider reusing a field for a different purpose to be a bad practise. Away from versioning, let’s say you have an old piece of code that you’ve forgotten about (or a college has written way back), reverencing this field, than it will reek havoc when updating the data incorrectly.

Instead you should always create a new column (or rename the old one), when giving it a new purpose.

The revisioning table should have all columns ever used, even if they no longer exist in the main table. At times that the field did not exists value will simply be NULL.

Note that this is only a solution for versioning the data and not for versioning the db structure. You should do that separately and treat the revisioning tables like any other table.

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