我正在为一家试图为其数据库记录实现 checkin / checkout 工作流类型的公司做短期契约(Contract)工作。
这是它应该如何工作的......
- 用户在应用程序中创建一个新实体。除了主实体表之外，还将填充大约 20 个相关表。
- 创建实体后，用户会将其标记为主实体。
- 其他用户只能通过“ checkout ”实体来更改主节点。多个用户可以同时 checkout 实体。
- 一旦用户对实体进行了所有必要的更改，他们就会将其置于“需要批准”状态。
- 授权用户审核实体后，可以将其提升为 master，这会将原始记录置于墓碑状态。
他们目前完成“ checkout ”的方式是复制所有表中的实体记录。主键包括 EntityID + EntityDate，因此它们在所有相关表中复制具有相同 EntityID 和更新的 EntityDate 的实体记录，并赋予其“已 checkout ”状态。当记录进入下一个状态(需要批准)时，重复再次发生。最终它将被提升为master，此时最终记录被标记为master，原始master被标记为dead。
这个设计对我来说似乎很可怕，但我理解他们为什么这样做。当有人从应用程序中查找实体时，他们需要查看该实体的所有当前版本。这是实现这一目标的一种非常直接的方法。但是他们在同一个表中多次表示同一个实体的事实并不适合我，他们复制每条数据而不是只存储增量的事实也不适合。
我很想听听您对设计的 react ，无论是积极的还是消极的。
我也将感谢您指出的任何资源，这些资源可能有助于了解其他人如何实现这种机制。
谢谢!
达维斯
最佳答案
我曾在这样一个系统上工作过，它支持在一家非常大的银行进行交易的静态数据。在这种情况下，静态数据是交易对手的详细信息、标准结算指令、货币(不是外汇汇率)等。数据库中的每个实体都是版本化的，更改实体涉及创建新版本、更改该版本并获取批准的版本。但是，他们不允许多人同时创建版本。
这导致数据库极其复杂，每次连接都必须考虑版本和批准状态。事实上，我为他们编写的软件是中间件，它将复杂的版本化数据抽象为最终用户应用程序可以实际使用的东西。
唯一可能使情况变得更糟的是存储增量而不是完整的版本化对象。所以这个答案的重点是 - 不要尝试实现增量!
关于sql - 如何管理同一记录的多个版本，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2533112/