Database design 事务数据库中快照的设计以及引用数据的版本控制

免责声明：我已经阅读了有关堆栈溢出和internet上的快照和版本控制主题的所有内容。我的要求不是审计跟踪或数据库级快照的版本跟踪。我已经花了一个多星期的时间独自研究并思考可能的选择。对不起，我可能错过了一些链接-如果我的问题的解决方案已经在其他线程中讨论过，请告诉我

它有点长；请容忍我

情况是这样的：我们正在尝试创建一种通用设计，以在事务数据库中存储事务数据的快照，并保留引用数据的修订历史记录

作为业务流程的一部分，用户可以按按钮发布特定对象。为了便于说明，我们假设用户可以在谈判开始之前发布供应商的提案。然后，在协商过程中的不同时间点，用户可以发布提案数据。该提案包含预算、销售目标和许多其他项目。对提案进行快照时，必须对所有链接的实体进行快照。最后，经过谈判，签订了一份合同。此时，必须创建合同的完整快照。并非合同中的所有实体都存在于标书中–有许多重叠实体，但标书和合同中有独特的实体

我们必须保持这些已发布版本和最新的活动版本可用。发布的版本在网站上提供，供供应商和管理团队参考。并非所有发布的版本都可以在网站上获得，但最后发布的建议书和最新发布的合同始终可以在网站上获得。此网站也必须从同一数据库填充

此外，财务用户可以决定仅快照预算，而销售经理可以快照销售目标。因此，快照可以在多个粒度上使用

我们还需要跟踪主数据的版本。随着时间的推移，跟踪关键主数据列的所有更改是一项业务需求。例如，我们有与销售目标关联的区域信息。区域名称可能会更改，我们希望跟踪这些更改。假设在提出建议时，该区域的名称为R1，并创建了一个快照。然后，区域名称更改为R2，然后创建另外两个快照。我们希望能够在这些时间点将销售目标链接到正确的地区名称，而不一定是最新的地区名称

我们在建模方面有一定的灵活性，因为我们有一个事务数据库和一个数据仓库数据库，我们可以决定将一些信息存储在事务数据库或数据仓库数据库中

这是我们的设计。我们有一个发布表，用于捕获有关发布数据的基本信息–发布者、发布日期、原因和发布对象的类型（提案或预算或销售目标）

我们将快照存储在与原始数据相同的表中。因此，提案快照将与实时提案一起存储在提案表中。我们在每个必须发布的表中都有一个名为publicationid的列。此列是发布表的FK。如果发布ID为空，则该记录为活动版本

我意识到这篇文章很长。因此，我没有列出场景细节，而是想在思维导图中快速总结设计注意事项。

现在，我们倾向于使用两种解决方案—这两种解决方案都将存储所有数据的快照，无论数据是否已更改。在保持表结构完整的同时只维护增量将需要一个非常复杂的存储过程，它必须在任何快照对象的每次插入/更新上运行。我不想沿着这条路线走下去，因为这将花费更长的时间，而且不管怎么说，流量也没有那么大

解决方案1：每次发布一个对象（如提案或预算），我们都会填充一个XML树，并将其保存在数据库中。只有最新版本需要在网站上提供，旧版本很少需要。考虑到这一点，我会因为使用XML而遇到大的性能问题吗？我们使用SQL Server。数据量并不是那么大

解决方案2：所有事务表都将有一个发布ID，引用数据将有开始和结束日期。每当发布对象时，我们都会复制所有事务记录并将发布ID放在那里，我们会复制所有引用数据记录并将快照日期作为结束日期。这将允许我们在发布过程之外对引用数据进行正常的版本控制

---

对于这两种方法的缺点，以及是否有其他更好的方案，我需要有经验的人的意见

我的方法是选择解决方案2。按顺序考虑您的设计考虑：

我会在快照中存储所有内容的副本。如果只存储更改，则会给自己带来从更改中获取所需快照的过程快照详细信息的问题。最初这不是一个问题，但随着模式、程序和流程的更改，您必须维护如何从自身已更改的流程检索所需快照的详细信息。可行，但可能脆弱

我会选择一个在您的图表中没有提到的选项，尽管在您对解决方案2的描述中已经略述了。这使用了一个非常类似于事务数据库的模式，但扩展到包含特定于快照的信息。您将publication ID作为外键，并指定引用的日期