This page last changed on Feb 15, 2010 by aaime.

Alternative data structure

The system as implemented stores all the history of a table evolution in a single table.

  • keeps things easy, only one table needs to be inspected for most versioning operations
  • during version enablement we just add a couple of columns that we know about, there is no need to actually understand the table structure and indexing
  • there is a certain overhead trying to access the current version of the data
  • version enabling tables with foreign keys is problematic as we change the primary key of the table, the version should be moved around as well (as part of the primary key) meaning that we'd need the datastore to handle the table nextworks

An alternative approach could be based on just extra tables:

  • we don't touch the original table
  • a replica of the original table xxx_history, with all the columns of the original table, plus version created and version expired is added, that contains only the old values of each row
  • a xxx_live table is created that contains the primary key and version created column, allows for knowing at which revision each live row was created

The main issue with this approach is that it makes harder to access history and requires a higher number of changes to be performed for each write.

Document generated by Confluence on May 14, 2014 23:00