在事务数据库中设计快照以及引用数据的版本控制
Sir*_*een 6 database-design static-data database-replication transactional-database
免责声明:我已经阅读了关于堆栈溢出和互联网上的快照和版本控制主题的所有内容.我的要求不是审计跟踪或数据库级快照的版本跟踪.我花了一个多星期的时间自己研究并思考可能的选择.对不起,我可能错过了一些链接 - 如果我的问题的解决方案已在其他一些帖子中讨论过,请指出我.
它有点长; 请多多包涵.
下面是这样的情况:我们正在尝试创建一个通用设计,以在事务数据库中存储事务数据的快照,并保留参考数据的修订历史记录.
作为业务流程的一部分,用户可以按下按钮来发布某个对象.为了便于说明,我们假设用户可以在协商开始之前从供应商发布提案.然后,在通过协商过程的不同时间点,用户可以发布提议数据.该提案包含预算,销售目标和许多其他项目.快照提案时,必须为所有链接的实体创建快照.最后,在谈判之后签订合同.此时,必须创建合同的完整快照.并非合同中的所有实体都存在于提案中 - 存在大量重叠的实体,但提案和合同中附有唯一的实体.
我们必须保留这些已发布的版本和最新的活动版本.已发布的版本可在网站上获得,供供应商和管理团队参考.并非所有已发布的版本都在网站上提供,但最新发布的提案和最新发布的合同始终在网站上提供.该网站还必须从同一数据库填充.
此外,财务用户可以决定仅对预算进行快照,销售经理可以对销售目标进行快照.因此,快照可以多种粒度使用.
我们还需要跟踪主数据的版本.随着时间的推移跟踪关键主数据列的所有更改是业务要求.例如,我们有与销售目标相关的区域信息.该地区的名称可能会更改,我们希望跟踪这些更改.我们假设在提议时,区域的名称是R1,并创建快照.然后,该区域的名称将更改为R2,然后创建其他2个快照.我们希望能够在这些时间点将销售目标链接到正确的区域名称,而不一定是最新的区域名称.
我们在建模方面具有一定的灵活性,因为我们有一个事务数据库和一个数据仓库数据库,我们可以决定将这些信息存储在事务数据库或数据仓库数据库中.
这是我们的设计.我们有一个出版物表,其中包含有关已发布数据的基本信息 - 发布者以及发布对象的日期,原因和类型(提案或预算或销售目标).
我们将快照存储在与原始数据相同的表中.因此,提案快照将与提案表中的实时提案一起存储.我们在每个必须发布的表中都有一个名为Publication ID的列.此列是Publication表的FK.如果Publication ID为null,则该记录是活动版本.
我意识到这个帖子非常冗长.因此,我没有列出场景细节,而是想到在思维导图中快速总结设计注意事项.
现在有两个我们倾向于的解决方案 - 两者都会存储所有数据的快照,无论它是否已经改变.在保持表结构完整的同时仅保持增量将需要非常复杂的存储过程,该存储过程必须在任何快照对象的每次插入/更新时运行.我不想沿着这条路走下去,因为这需要更长的时间,而且音量也不是那么大.
解决方案1:每次发布一个对象(如提议或预算),我们将填充XML树并将其保留在数据库中.只需要在网站上提供最新版本,很少需要旧版本.鉴于此,由于使用XML,我是否会遇到大的性能问题？我们使用SQL Server.数据量并不大.
解决方案2:所有事务表都具有发布ID,参考数据将具有开始和结束日期.每当发布一个对象时,我们都会复制所有事务记录并将发布ID放在那里,我们将复制所有参考数据记录并将快照日期作为结束日期.这将允许我们在发布过程之外对参考数据进行正常版本控制.
我需要有经验的人士就这两种方法的缺点以及是否还有其他更好的方案提出意见.
我的方法是选择解决方案 2。按顺序考虑您的设计考虑因素：
我会在快照中存储所有内容的副本。如果您仅存储更改，那么您就会遇到对流程详细信息进行快照以从更改中获取所需快照的问题。最初这不是问题，但随着模式、程序和流程的更改，您将必须维护如何从本身已更改的流程中检索所需快照的详细信息。可行，但可能很脆弱。
我会选择您的图表中未提及的选项，尽管在您对解决方案 2 的描述中概述了这一选项。这使用的模式与事务数据库的模式非常相似，但扩展为包括特定于快照的信息。您提到出版物 ID 作为外键，以及参考数据的日期。您可能会发现您需要与交易数据相关的其他信息，例如日期。
相同的模式是不行的 - 您已经指出（出版物 ID）相同的模式是不够的。您发布的内容中没有任何内容表明您需要采用针对阅读而优化的不同架构。即使这被证明是必需的，也可以在稍后阶段合并，以当前的扩展模式作为起点。我对 XML 树没有太多经验，但会问“当您有可以利用现有基础设施的替代技术时，为什么要引入另一种技术呢？” 您从这种方法中感受到的任何优势都必须非常重要，才能避免放弃现有架构的优势。类似的考虑也适用于非规范化数据库。在确实有必要之前为什么要去那里？
我将再次采用跟踪版本控制和快照的方法。您在解决方案 2 中给出了这种方法的主要优点。我将添加参考数据的快照作为快照过程的一部分，而不是版本控制过程。（即，当拍摄快照时，确保适当的参考表构成快照的一部分）。从您的描述看来，您有两个不同的要求恰好利用相同的数据 - 快照和版本控制。它们之间似乎几乎没有依赖性，因此您应该使它们尽可能独立 - 缺乏耦合。
您提到可能使用数据仓库作为存储，尽管您的解决方案中没有具体提及。如果您的卷如您所建议的那样很低，那么我会认为单独的数据库就足够了。您确实给人的印象是快照的数据量和用户量都很低，因此似乎没有使用数据仓库的表面案例。同时，仓库确实有一些机制来存储此类历史数据，以供读取和分析。
很抱歉，我没有在这里直接回答您的问题 - 但我希望这能为您所述的情况提供一些指导和另一种观点。