Database versioning

Question

I have made few projects (CMS and EC system) that required to have some data versioned.

Usually I come with that kind of schema

+--------------+
+          


        

Answer 1

I used to work on a system with historical data, and we had a boolean to indicate which one was the latest version of the data. Of course you need to maintain the consitency of the flag at the applicative level. Then you can create indexes that use the flag and if you provide it in the where clause it's fast.

Pro:

• easy to understand
• does not require major change to your (existing) database schema
• no need to copy old data in another table, only flag is updated.

Cons:

• flag need to be maintained at applicative level

Otherwise, you can rely on a separate history table, as suggested in several answers.

Pro:

• clean sepration of history from actual data
• possible to have a db-level cascade delete between actual data and its history, in case the entity is removed

Cons:

• need 2 queries (or a union) if you want the complete history (that is, old data + current data)
• the row that corresponds to the latest version of the data will be updated. I heard that update are slower than insert, depending on the "size" of the data that changed.

What is best will depend from your use case. I had to deal with a document management system where we wanted to be able to version document. But we also had feature like reverting to old version. It was easier to use a boolean to speed up just the operation that required the last one. If you have real historical data (which never change) probably a dedicated history table is better.

Does the concept of history fit in your domain model? If no, then you have a db schema that differs from your conceptual domain model. If at the domain level, the actual data and the old data need to be handled the same way, having two tables complicates the design. Just consider the case you need to return the complete history (old + new). The easiest solution would be to have one class for each table, but then you can't return a list as easily as if you have only one table. But if these are two distinct concepts, then it's fine to have history be first-class in your design.

I would also recommend this article by M. Fowler also interesting when it comes to dealing with temporal data: Patterns for things that change with time