如何管理同一记录的多个版本

Question

我正在为试图为其数据库记录实施签入/签出类型工作流的公司进行短期合同工作。

下面是它如何工作？

1. 用户在应用程序中创建一个新的实体。除了主实体表之外，大约还有20个相关的表格将被填充。
2. 创建实体后，用户会将其标记为主。
3. 另一个用户只能通过“签出”实体来更改主人。多个用户可以同时检出实体。
4. 一旦用户对实体进行了所有必要的更改，他们就会将其置于“需要批准”状态。
5. 经过授权用户查看实体后，他们可以将其提升为主，这会将原始记录置于逻辑状态。

他们目前完成“检出”的方式是通过复制所有表中的实体记录。主键包括EntityID + EntityDate，因此它们使用相同的EntityID和更新的EntityDate复制所有相关表中的实体记录，并为其提供“已签出”状态。当记录进入下一个状态（需要批准）时，复制会再次发生。最终将被提升为主，届时最终记录被标记为主，并且原始主记录被标记为死亡。

这个设计对我来说似乎很难理解，但我明白他们为什么这么做。当有人从应用程序中查找实体时，他们需要查看该实体的所有当前版本。这是实现这一目标的一个非常直接的方法。但是他们在同一个表中多次代表同一个实体的事实并不适合我，他们也没有重复每一条数据而不是只存储增量。

我会有兴趣听到您对设计的反应，无论是正面还是负面。

我也很感激任何资源，你可以指出我可能是有用的看到别人如何实现这样的机制。

谢谢！
Darvis

Answer 1

我在这样一个系统上工作，它支持在一家非常大的银行进行交易的静态数据。在这种情况下，静态数据就像交易对手的细节，标准结算指令，货币（而非外汇汇率）等。数据库中的每个实体都进行了版本控制，并更改了涉及创建新版本的实体，更改了该版本并获得了版本被批准。但是他们并没有让多人同时创建版本。

这导致了一个非常复杂的数据库，每个连接都必须考虑版本和审批状态。实际上，我为他们编写的软件是中间件，它将这种复杂的，版本化的数据抽象为最终用户应用程序实际可以使用的数据。

唯一可能使它变得更糟的是存储增量而不是完整的版本化对象。所以这个答案的重点是 - 不要尝试实现增量！

Answer 2

你正在描述一个自制软件Content Management System，它可能随着时间的推移被一起攻击，因为你陈述的原因，冗余和低效，并且考虑到如果没有大规模的组织努力，公司的这种系统的性质不可能被移动。

Answer 3

这看起来像是一个时态数据库模式的例子 - 通常，在这种情况下，在实体的键（EntityID，在您的情况下）和数据库中的行主键之间存在区别大小写，{EntityID，日期}，但通常是一个简单的整数）。您必须接受同一实体在其历史记录的不同时间点在数据库中多次表示。每个数据库行都有一个唯一的ID;只是你的数据库正在跟踪版本，而不是实体。

您可以像这样管理数据，并且它可以很好地跟踪数据更改并提供问责制（如果需要），但它会使您的所有查询都变得更加复杂。

您可以阅读有关原理背后，和时间数据库on Wikipedia