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

想回复我的子孙们千古

我正在为一家试图记录其数据库实施工作流程的公司进行短期合同。
  T. R& ]3 D% K5 H5 W4 B' C3 P这是应该如何工作的…
[ol]用户在应用程序中创建一个新的实体。除主实体表外，还将填写约20个相关表。
. P8 a# T' g) O6 {! U' M创建实体后，用户将其标记为主实体。
' i. D5 L9 {# N+ _另一个用户只能通过签出实体更改母版。多个用户可以同时签署实体。
用户对实体进行所有必要的更改后，将其置于需要批准状态。
授权用户查看实体后，可将其升级为母版，将原始记录置于墓碑状态。[/ol]他们目前通过在所有表中复制实体记录来完成签名。主键包括EntityID  
EntityDate，因此，它们在所有相关表中使用相同的表EntityID和更新的EntityDate复制物理记录，并将其状态设置为已签名。当记录进入下一个状态（需要批准）时，重复将再次发生。最后，它将升级为母版，最终记录标记为母版，原始母版标记为无效。
这个设计对我来说似乎很丑，但我知道他们为什么这么做。当有人从应用程序中找到实体时，他们需要检查实体的所有当前版本。这是实现这一目标的一个非常简单的方法。然而，他们多次表示，同一实体的事实与我相处并不愉快，他们复制每个数据而不仅仅是存储增量数据也不是一件好事。
无论是积极的还是消极的，我都想听听你对设计的反应。
我也很感激你能指出的任何资源，这可能对了解别人如何实现这种机制非常有用。
& x: n) {" j2 F4 _& ?* g: y% V) ^谢谢！
达维斯
                                                               
    解决方案:                                                               
                                                                我已经在这样的系统上工作，支持大银行交易的静态数据。在这种情况下，静态数据是交易对手的详细信息、标准结算指令和货币(不是)FX汇率)等等。数据库中的每个实体都进行了版本控制，包括创建新版本、更改版本和获取版本。这个版本已经被批准了。然而，他们不允许多人同时创建版本。
这导致了一个极其复杂的数据库，每个连接都必须考虑版本和批准状态。事实上，我为他们编写的软件是中间件，它可以抽象成最终用户应用程序可以实际使用的复杂版本化数据。
唯一可能使情况更糟的事情是存储增量而不是完整的版本化对象。因此，答案的重点是-不要试图实现增量！