我正在为一家公司做短期合同工作，该公司试图为其数据库记录实施签入/签出类型的工作流程。
这是它应该如何工作的......
- 用户在应用程序中创建一个新实体。除了主实体表之外，还将填充大约 20 个相关表。
- 创建实体后，用户会将其标记为主实体。
- 另一个用户只能通过“签出”实体来对主实体进行更改。多个用户可以同时结帐该实体。
- 一旦用户对实体进行了所有必要的更改，他们就会将其置于“需要批准”状态。
- 授权用户审查实体后，他们可以将其提升为主实体，这会将原始记录置于逻辑删除状态。
他们当前完成“签出”的方式是复制所有表中的实体记录。主键包括 EntityID + EntityDate，因此它们使用相同的 EntityID 和更新的 EntityDate 复制所有相关表中的实体记录，并为其赋予“已签出”状态。当记录进入下一个状态（需要批准）时，重复会再次发生。最终它将被提升为master，此时最终记录被标记为master，而原始master被标记为死亡。
这个设计对我来说似乎很可怕，但我理解他们为什么这样做。当有人从应用程序内查找实体时，他们需要查看该实体的所有当前版本。这是实现这一目标的一种非常简单的方法。但它们在同一个表中多次表示同一实体的事实并不适合我，而且它们复制每条数据而不是仅存储增量的事实也不适合我。
我很想听听您对设计的反应，无论是积极的还是消极的。
我也将不胜感激您可以向我指出的任何资源，这些资源可能有助于了解其他人如何实现这种机制。
Thanks!
Darvis
我曾经开发过这样的系统，该系统支持一家非常大的银行的静态交易数据。在这种情况下，静态数据是交易对手的详细信息、标准结算指令、货币（不是外汇汇率）等。数据库中的每个实体都是版本化的，更改实体涉及创建新版本、更改该版本并获取版本已批准。然而，他们并没有让多人同时创建版本。
这导致数据库极其复杂，每个连接都必须考虑版本和批准状态。事实上，我为他们编写的软件是中间件，它将复杂的版本化数据抽象为最终用户应用程序可以实际使用的东西。
唯一可能使情况变得更糟的是存储增量而不是完整的版本化对象。所以这个答案的要点是——不要尝试实现增量！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
