事务数据库中的快照设计以及参考数据的版本控制

Question

免责声明：我已阅读有关堆栈溢出和 Internet 上的快照和版本控制主题的所有内容。我的要求不是审计跟踪或数据库级快照的版本跟踪。我花了超过 1 周的时间自行研究并考虑可能的选择。抱歉，我可能错过了一些链接 - 如果我的问题的解决方案已经在其他线程中讨论过，请指出我那里。

有点长；请多多包涵。

情况如下：我们正在尝试创建一种通用设计，以将交易数据的快照存储在我们的交易数据库中，并保留参考数据的修订历史记录。

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

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

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

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

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

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

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

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

现在我们倾向于两种解决方案 - 两者都可以存储所有数据的快照，无论数据是否已更改。在保持表结构完整的同时仅维护增量将需要一个非常复杂的存储过程，该存储过程必须在任何快照对象的每次插入/更新时运行。我不想走这条路，因为这会花费更长的时间，而且数量也不会那么大。

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

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

我需要有经验的人就这两种方法的缺点以及是否还有其他更好的方案提出意见。

Answer 1

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

1. 我会将所有内容的副本存储在快照中。如果您只存储更改，您就会给自己制作快照过程细节的问题，以便从更改中获取所需的快照。最初这不是问题，但随着模式、程序和流程的变化，您将必须维护有关如何从本身已更改的流程中检索所需快照的详细信息。可行，但可能很脆弱。

2. 我会选择您的图表中未提及的选项，尽管在您对解决方案 2 的描述中已勾勒出来。这使用的架构与事务数据库的架构非常相似，但已扩展为包含特定于快照。您提到发布 ID 作为外键，并提到参考数据的日期。您可能会发现需要与交易数据相关的其他信息，例如日期。

3. 相同的架构不行 - 您已经指出（Publication ID）相同的架构是不够的。您发布的内容中没有任何内容表明您需要采用针对阅读进行优化的不同模式。即使这被证明是必需的，它也可以在稍后阶段合并，以当前的扩展模式为起点。我在 XML 树方面没有太多经验，但会问“当您有可以利用现有基础架构的替代方案时，为什么还要引入另一种技术？”您从这种方法中感知到的任何优势都必须非常重要，才能避免放弃现有架构中的杠杆优势。类似的考虑适用于非规范化的数据库。为什么要在证明需要这样做之前去那里？

4. 我再次采用跟踪版本控制和快照的方法。您在解决方案 2 中给出了这种方法的主要好处。我会将参考数据的快照添加为快照过程的一部分，而不是版本控制过程。 （即，当拍摄快照时，确保适当的参考表构成快照的一部分）。从您的描述看来，您有两个不同的要求碰巧使用相同的数据 - 快照和版本控制。它们之间似乎几乎没有依赖关系，因此您应该尽可能保持它们独立 - 缺乏耦合。

5. 您提到可能将数据仓库用作存储，但在您的解决方案中没有特别提及。如果您的数量如您所建议的那样低，那么我会认为单独的数据库就足够了。您确实给人的印象是快照的数据量和用户量都很低，因此似乎没有使用数据仓库的初步案例。同时，仓库确实有一些机制可以准确存储这类历史数据，用于读取和分析。

很抱歉，我没有在这里直接回答您的问题 - 但我希望这可以为您所陈述的情况提供一些指导和另一种看法。