Question

We are developing a large applications which are related to business. You can find these applications similar to some ERP, CRM, etc.

Now we have a requirement that we need all the data which are entered by the user to be versioned.

For example: at some point of time, the user would need to see what’s the change history of a particular Purchase Order?

I am looking for a very generic versioning handler (not rigid), which could handle even cases if some some business data attributes gets changed. This single versioning handler should be able to work with almost any type of business objects/data.

What would be the best programming/database design to handle these.

Any Ideas or Opinions?

PS: I have added some programming tags as I want programmers to entertain this thread and give their ideas.

EDIT:
I am looking for a very optimized way, somewhat similar to having diffs beings stored rather than storing the objects in a serialized/dumping way.

Answer 1

It may be just the right time to adopt purely functional lazy data structures.

In a nutshell, this requires banning any mutating operations on your Objects, i.e. making all your Object instances immutable. Then you redesign all the operations which change existing Object to creating new Object instance based on the old one.

For example, let you have an Order instance which contains a list of OrderItems and you need to add a specific OrderItem to that list. What you do in this case is creating new instance of Order by replacing its items list by a new list, which in turn is created by cons‘ing the new OrderItem to the old list.

Let me illustrate that example further in pictures. Imagine a storage of objects (let it be RAM or relational database, anything):

Address | Object             | Created by
--------+--------------------+------------------------------------------
   1000 | list of OrderItems | empty list constructor
   1001 | Order              | Order constructor, uses address 1000
                  ...         
   1300 | OrderItem          | ...
   1501 | list of OrderItems | cons of addr 1300 to addr 1000
   1502 | Order              | replace order_items in addr 1001 by addr 1501

The very structure of storing data in this way is persistent (Chris Okasaki elaborates on this in his thesis, for example). You can restore any version of an Object by just following its creation history; versioning becomes trivial. Just remember the main point: don’t mutate data, create new instances instead.