How to version relational data? - mysql

Question

Versioning is straightforward with entry such as page that has name. I would have a table page_version that stores every previous value of the row every time page is updated, whether using triggers or application logic.
CREATE TABLE `page` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(100) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
INSERT INTO `page` (`id`, `name`)
VALUES
(1,'Foo');
CREATE TABLE `page_version` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`page_id` int(10) unsigned NOT NULL,
`name` varchar(100) COLLATE utf8_unicode_ci NOT NULL,
`entry_timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `page_id` (`page_id`),
CONSTRAINT `page_version_ibfk_1` FOREIGN KEY (`page_id`) REFERENCES `page` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
INSERT INTO `page_version` (`id`, `page_id`, `name`, `entry_timestamp`)
VALUES
(1,1,'foo','2013-09-19 20:27:06');
In this example, I know that page.name was changed from "foo" to "Foo". If it had been changed again (e.g., to "Bar"), then "Foo" value would be added to page_version and original row page.name updated to "Bar".
However, how to track version of dependant values that might have a one-to-many relation with the entry? e.g. if the latter schema was supplemented by adding category and category_page tables.
CREATE TABLE `category` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(100) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
INSERT INTO `category` (`id`, `name`)
VALUES
(1,'One'),
(2,'Two');
CREATE TABLE `page_category` (
`page_id` int(10) unsigned NOT NULL,
`category_id` int(10) unsigned NOT NULL,
PRIMARY KEY (`page_id`,`category_id`),
KEY `category_id` (`category_id`),
CONSTRAINT `page_category_ibfk_2` FOREIGN KEY (`category_id`) REFERENCES `category` (`id`) ON DELETE CASCADE,
CONSTRAINT `page_category_ibfk_1` FOREIGN KEY (`page_id`) REFERENCES `page` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
How to capture the change (on the same change when foo was changed to Foo) if user has added a new category ("Two") to the page?

Answer 1

You use the term "version" but, as jeremycole commented, you are not clear on the reason for needing it.
If it is simply to provide a history of changes to the data over time, then an additional table for each table in your database will suffice; it appears this is what you already have with your page_version table.
These history tables will allow you to retrieve the state of your "object" from the database at a point in time, which is why I use the term "history". Calling it a version implies there is number, or some other identifier, applied to the collection of data that defines the "object". You do not appear to have this in your table structure.
Rebuilding the relational data from a point in time will involve writing your normal queries joining the appropriate tables, but with the addition of matching the row of data at, or before, the point in time you are interested in. While this can be done, it becomes unwieldy when the number of tables in the join increases.
Another way is to create a version of your object in the application and store it in the database. Use, for example, XML or JSON to encode your object and put the whole thing, as a string, in a table along with the version number and date stamp.
This makes it easy to retrieve an entire object given a version number, although it requires the application to construct the in-memory object from the XML/JSON data before it can be written to the database again (in the event you want to revert to a previous version). This shouldn’t be too hard though since you're already be reading/writing objects to your relational tables, you would just need to add the object streaming code.
Without knowing more about your reasons for storing the history/version it's hard to recommend one method over the other. I use the simple history table, managed by triggers, to record changes to the data in our system but then we don't have the requirement to "roll back" to a previous version. We use the history for the odd occasion someone goofs and we need to undo a single edit, and as a "blame" trail by recording the username of the person who made the change :)
I recommend you read Developing Time-Oriented Database Applications in SQL by Richard Snodgrass (links to the PDF are in the first paragraph of the "Books" section). It's not a short book but it has helped me immensely.

Answer 2

If you want to track version in the same place (say the same entry_timestamp field) you can achieve that with trigger on page_category table.
See more here, there is an example on the bottom of that page.