免责声明：我已经阅读了有关堆栈溢出和 Internet 上的快照和版本控制主题的所有内容。我的要求不是审计跟踪或数据库级快照的版本跟踪。我花了超过 1 周的时间自行研究并考虑可能的选择。抱歉，我可能错过了一些链接 - 如果我的问题的解决方案已经在其他线程中讨论过，请指出我那里。
有点长；请多多包涵。
情况如下：我们正在尝试创建一个通用设计，以将事务数据的快照存储在我们的事务数据库中，并保留参考数据的修订历史。
作为业务流程的一部分，用户可以按下按钮发布特定对象。为了说明的目的，假设用户可以在谈判开始之前发布来自供应商的提案。然后，通过协商过程，在不同的时间点，用户可以发布提案数据。该提案包含预算、销售目标和许多其他项目。对提案进行快照时，必须对所有链接实体进行快照。最后，经过谈判，签订合同。此时，必须创建合约的完整快照。并非合同中的所有实体都存在于提案中——有很多重叠的实体，但提案和合同都有独特的实体。
我们必须保留这些已发布的版本和最新的活动版本。已发布的版本可在网站上获得，供供应商和管理团队参考。并非所有已发布的版本都在网站上提供，但最后发布的提案和最新发布的合同始终在网站上可用。该网站也必须从同一数据库中填充。
此外，财务用户可以决定仅对预算进行快照，而销售经理可以对销售目标进行快照。因此，快照可在多个粒度上使用。
我们还需要跟踪主数据的版本。随着时间的推移跟踪对关键主数据列的所有更改是一项业务需求。例如，我们有与销售目标相关的区域信息。区域的名称可以更改，我们希望跟踪这些更改。让我们假设在提案时，区域的名称是 R1，并创建了一个快照。然后，区域名称更改为 R2，然后创建另外 2 个快照。我们希望能够在这些时间点将销售目标链接到正确的区域名称，而不一定要链接到最新的区域名称。
我们在建模方面具有一定的灵活性，因为我们同时拥有事务数据库和数据仓库数据库，我们可以决定将其中一些信息存储在事务数据库或数据仓库数据库中。
这是我们的设计。我们有一个发布表，它捕获有关已发布数据的基本信息——发布者和发布日期、原因和发布对象的类型（提案或预算或销售目标）。
我们将快照存储在与原始数据相同的表中。因此，提案快照将与提案表中的实时提案一起存储。我们在每个必须发布的表中都有一个名为 Publication ID 的列。此列是 Publication 表的 FK。如果发布 ID 为空，则该记录是活动版本。
我意识到这篇文章很长。因此，我没有列出场景细节，而是想在思维导图中快速总结设计注意事项。
现在我们倾向于两种解决方案 - 两者都将存储所有数据的快照，无论它是否已更改。在保持表结构完整的同时仅维护增量将需要一个非常复杂的存储过程，该存储过程必须在任何快照对象的每次插入/更新时运行。我不想走这条路，因为这会花费更长的时间，而且数量也不会那么大。
解决方案 1：每次发布对象（如提案或预算）时，我们将填充 XML 树并将其保存在数据库中。网站上只需要提供最新版本，很少需要旧版本。鉴于此，由于使用 XML，我会遇到很大的性能问题吗？我们使用 SQL Server。数据量不是很大。
解决方案 2：所有事务表都有一个发布 ID，参考数据有开始和结束日期。每当发布对象时，我们都会复制所有事务记录并将发布 ID 放在那里，我们将复制所有参考数据记录并将快照日期作为结束日期。这将允许我们在发布过程之外对参考数据进行正常版本控制。
我需要有经验的人就这两种方法的缺点以及是否还有其他更好的方案提出意见。