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

Question

我正在为一家公司做短期合同工作，该公司正在尝试为其数据库记录实施签入/签出类型的工作流程。

这是它应该如何运作......

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

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

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

我很想听听您对设计的反应，无论是积极的还是消极的。

我也很感激您可以指出的任何资源，这对于了解其他人如何实施此类机制可能会有所帮助。

谢谢！
Darvis

Answer 1

我曾经在这样的系统上工作过，它支持在一家大型银行进行交易的静态数据。在这种情况下，静态数据类似于交易对手的详细信息，标准结算指令，货币（不是外汇汇率）等。数据库中的每个实体都是版本化的，并且更改实体涉及创建新版本，更改该版本并获取版本已批准。然而，他们并没有让多人同时创建版本。

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

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

Answer 2

你正在描述一个可能随着时间的推移而被黑客攻击的自制Content Management System - 由于你说的原因 - 是多余的和低效的，并且考虑到公司中这种系统的性质，如果没有大规模的组织，就不太可能被取代努力。

Answer 3

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

您可以管理这样的数据，它可以非常擅长跟踪数据更改，并提供问责制（如果需要），但它会使您的所有查询更加复杂。

您可以阅读背后的基本原理和时态数据库的设计on Wikipedia