Time and Time Again: Managing Time in Relational Databases, Part 5: Version Pattern 3 – DMReview

Time and Time Again: Managing Time in Relational Databases, Part 5: Version Pattern 3 – DMReview

The business requirement for Version Pattern 3 is to be able to show what an object was like at any point in its lifetime. To do this, we must retain the before-update state of an object, not just the after-update state. We must retain a versioned history of changes to the state of an object. This means that in place of the Policy table we have been using thus far, we will need a Policy Version table.