How to implement dynamic business objects / data?

Question

We develop large business-related applications. You can find these applications similar to some ERP, CRM, etc.

Now we have a requirement that we need all the data that the user enters for the version.

For example: after some time, the user will have to see what is the change history of a particular purchase order?

I am looking for a very general version handler (not hard) that could handle even cases where some business data attributes were changed. This single version control handler should work with almost any business object / data.

What will be the best programming / database design for processing them.

Any ideas or opinions?

PS: I added some programming tags because I want programmers to entertain this topic and give their ideas.

EDIT: I'm looking for a very optimized way, somewhat similar to the fact that it stores different creatures, rather than storing objects in a serialized / dumped way.

Answer 1

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

In short, this requires the prohibition of any mutating operations on your Objects, i.e. creating all instances of an immutable object. Then you reverse engineer all operations that modify the existing object to create a new instance of the object based on the old one.

For example, suppose you have an instance of Order that contains an OrderItem list, and you need to add a specific OrderItem to this list. What you do in this case is to create a new instance of Order , replacing its list of elements with a new list, which, in turn, creates a cons ' new OrderItem in the old list.

Let me illustrate this example further in the photographs. Imagine a repository of objects (let it be RAM or a relational database, whatever):

  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 data storage structure itself is thus constant (Chris Okasaki describes this in detail in his thesis ). You can restore any version of an object simply by following its creation history; version control is becoming trivial. Just remember the main thing: do not mutate the data, do not create new instances.

Answer 2

Something like Hibernate Envers strings - an entity verification solution seems to be well suited to your requirements.

Answer 3

If you are not doing invasive (I see what is common, as competing with invasive), I think your option is to complete serialization. In each version, you simply take a picture of the object and serialize it according to what is appropriate.

If you were confined to a database, for example, just save it with a time stamp and take the most recent time stamp as the current one. However, I would not think of it as a database problem. You are allowed to serialize outside the system for things like partial results, testing, sanity, etc.

Answer 4

Basically you should be able to compare the fields of an existing object and a new object and keep the differences.

This is usually done for highly sensitive objects in order to track the number of changes in that particular row / account. It would be redundant if this were done for all tables. Differences can be saved asynchronously in a separate history table that matches the same online table layout.

Answer 5

I had to do something like this in the past.

I found that the easiest way, if you start from scratch, is to add an extra column to the object data table that contains the index of the replacement object. If the value was zero, I knew that this was the latest version. It also meant that the objects were never deleted, although I later added functionality that would allow me to delete the past history.

In fact, the index becomes the version number of the object in question, and any query to the database for the latest version will use the WHERE NextVersionIndex=0 qualifier WHERE NextVersionIndex=0 .

If you do not start from scratch, this can be implemented in a living system by adding an additional table to store these values ​​- the object index, index of the previous version, index of the next version.