DELETE FROM Foo WHERE id = "1024" OR id = 1024,9" OR id = "1024,8";
UPDATE Foo SET id = "1024" where id = "1024,7";
[download]

What's wrong here? You say it's "nasty" but I don't see anything particularly bad about it.

The thing is, reversion is an uncommon operation. It can be a little hairy and nothing bad will happen. There will only be one place in the code handling reversion. However, linking between objects in join tables and general querying will happen all over the place. If that requires two columns per table for every join I know we'll have problems.

-sam

I say it's nasty because if you have referential integrity constraints on other tables pointing to this, you won't be able to simply delete where id = "1024". Also, doesn't your sample lose all versions after 7? I expect people would want to keep those.

I still don't think multi-column keys are a big deal, especially if you hide them with a view. However, now I'm wondering if versions are really what you're after. What most people really mean when they say they want versioning of content is the ability to have a live version and an in-progress version. They couldn't care less about going back to old versions but they want to be able to put edits to the content through some kind of workflow process before making it live. If that's your situation, maybe you can get away with something simpler.