如何对动态业务对象/数据进行版本控制？
我们正在开发与业务相关的大型应用程序。你可以发现这些应用程序类似于一些ERP、CRM等。
现在我们有一个要求，我们需要对用户输入的所有数据进行版本控制。
例如：在某个时间点，用户需要查看特定采购订单的更改历史记录是什么？
我正在寻找一个非常通用的版本控制处理程序（不是严格的），它甚至可以处理某些业务数据属性发生更改的情况。这个单一版本控制处理程序应该能够处理几乎任何类型的业务对象/数据。
处理这些问题的最佳编程/数据库设计是什么？
有什么想法或意见吗？
PS：我添加了一些编程标签，因为我希望程序员能够娱乐这个线程并给出他们的想法。
编辑： 我正在寻找一种非常优化的方法，有点类似于存储差异而不是以序列化/转储的方式存储对象。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
现在可能正是采用纯函数式惰性数据结构的最佳时机。
简而言之，这需要禁止对对象进行任何变异操作，即使所有对象实例不可变 。然后，您重新设计所有更改现有对象的操作，以在旧对象实例的基础上创建新的对象实例。
例如，假设您有一个
Order实例，其中包含OrderItem列表，并且您需要将特定的OrderItem添加到该列表。在这种情况下，您要做的是通过用新列表替换其项目列表来创建Order的新实例，而新列表又由 缺点'将新的OrderItem添加到旧列表中。让我用图片进一步说明这个例子。想象一下对象的存储（可以是 RAM 或关系数据库，任何东西）：
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以这种方式存储数据的结构是持久的（Chris Okasaki 在 他的论文）。您可以通过跟踪对象的创建历史记录来恢复对象的任何版本；版本控制变得微不足道。只需记住要点：不要改变数据，而是创建新实例。
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
Orderinstance which contains a list ofOrderItems and you need to add a specificOrderItemto that list. What you do in this case is creating new instance ofOrderby replacing its items list by a new list, which in turn is created by cons'ing the newOrderItemto 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 1501The 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.
类似于 Hibernate Envers - 实体审计解决方案，似乎很适合您的要求。
Something along the lines of Hibernate Envers - an Entity Auditing solution, appears to be a good fit for your requirements.
如果您不进行侵入性（我认为通用与侵入性竞争），那么我认为您的选择是进行完整序列化。在每个版本中，您只需拍摄对象的快照并将其序列化为适当的内容。
例如，如果您仅限于数据库，只需将其与时间戳一起保存，并将最近的时间戳作为当前时间戳。不过，我会避免将其视为纯粹的数据库问题。您应该被允许在系统外部序列化部分结果、测试、健全性等。
If you aren't doing invasive (I see generic as competing with invasive), then I think your option is to do full serialization. At each version you just take a snapshot of the object and serialize it to whatever is appropriate.
If you were confined to a database for instance, just save it with a timestamp and take the most recent timestamp as current. I would avoid thinking about it as solely a database problem though. You should be allowed to serialize outside of the system for things like partial results, testing, sanity, etc.
基本上，您应该能够比较现有对象和新对象的字段并保留差异。
通常，这将为高度敏感的实体完成，以跟踪对该特定行/帐户的更改数量。如果对所有表都这样做，那就有点大材小用了。差异可以异步保存在与在线表的相同设计相匹配的单独历史表中。
Basically you should be able to compare the fields of an existing object and the new object and persist the differences.
Typically this would be done for highly sensitive entities to keep track of the number of changes to that particular row/account. It would be an overkill if it is done for all the tables. The differences can be persisted asynchronously in a separate history table that matches the same design of the online tables.
我过去不得不做类似的事情。
我发现，如果从头开始，最简单的方法是在对象数据表中添加一个额外的列来保存替换对象的索引。如果持有的值为零，那么我就知道它是最新版本。这也意味着对象永远不会被删除，尽管我后来添加了允许删除过去历史记录的功能。
实际上，索引成为相关对象的版本号，并且对数据库的最新版本的任何查询都将使用限定符
WHERE NextVersionIndex=0。如果不是从头开始，可以通过添加额外的表来存储这些值（对象索引、上一个版本索引、下一个版本索引）来将其实现到实时系统中。
I've had to do something similar to this in the past.
I found that the easiest way, if starting from scratch was to add an extra column in the objects data table that held the index of the replacement object. If the value held was zero then I knew that it was the latest version. This also meant that objects were never deleted, although I later added functioanlity that would allow the deletion of the past history.
Effectively the index becomes the version number of the object in question and any query to the DB for the latest version would use the qualifier
WHERE NextVersionIndex=0.If not starting from scratch this can be implemented into a live system by adding an extra table to store these values - Object Index, Previous version index, next version index.