这是交易/挑战，
我们必须跟踪信息及其线性变化。我们还必须跟踪不按顺序的变化。例如A发生了然后B发生了。过了一段时间，我们学到了实际上在B之前发生的C.随着这个挑战，我们有许多对象需要相互关联的版本。如果它是一个需要版本化的单个表/对象......没什么大不了的。但是，对于多个对象，现在我们进入更复杂的链接。并且，抛出无序事件的概念只会使事情复杂化。
签入代码时，您无法执行无序操作。发生了东西，然后你修复/改进它。但是，在某些系统中，您无法在事件发生时或以线性顺序获取所有信息。然而，即使它与您收到信息的时间线不同，您仍然需要计算真实世界的事件时间线。
层次结构的简短示例:(每个对象都必须进行版本控制）
从一个角度来看，如果我需要访问当前的策略，我应该看到现在的一切。但是，如果我需要在3周前查看作为交易的一部分而改变的内容，我必须能够看到它之前的内容......究竟是什么改变了...然后是改变后的内容。
我已经编写了一个模式来尝试解决所有这些问题，同时还尝试仅存储已更改的信息（不会在每次更改版本时复制整个堆栈 - 我在尝试时将其视为常见做法解决这个问题）。我确实环顾网络，并且熟悉所有GoF模式以及其他一些模式。不管怎样，要么我错过了这条船而且过于复杂，要么我只是不常遇到这种情况的人之一。
我会尽快发布我工作过的模式。首先，你的想法＆amp;智慧。如果您有任何疑问，请随时提出。谢谢你的时间！
答案 0 :(得分：0)
最终有2个主要策略来实现这一目标，核心权衡是空间或复杂性。对于空间交易，您可以复制完整的数据堆栈并对其进行版本化。为了折衷复杂性，您需要管理一个版本化的轻型键/指针系统。
为了简单起见，我们实施了空间交易。
需要5个核心密钥。主ID，LinearInstanceID，LinearPreviousID，NonLinearInstanceID和NonLinearPreviousID。
拼图的最后一部分是选择工作流来确定何时需要整个附加对象堆栈的新版本。通常这很容易，因为您有自然的业务级别事务。
<强>事件
- 所有事件：创建新的唯一主要ID
第1版：
新版本（正常线性）：
新版本（不寻常的非线性）：
<强>优势
我知道这似乎有很多联系，但这里有一些好处：
在当前时间轴或所有时间轴上轻松导航到这些区域
我希望这可以帮助那些情况相同的人。如果您有任何问题/意见，请随时告诉我。如果视觉辅助有帮助，请告诉我。