如何使用修订历史记录设计数据库？

Question

我是为我们的公共站点构建新内容管理系统的团队的一员.我正在尝试找到构建版本控制机制的最简单,最好的方法.对象模型非常基础.我们有一个抽象的"BaseArticle"类,其中包含版本无关/元数据的属性,例如"Heading"和"CreatedBy".许多类继承自此类,例如"DocumentArticle",它具有属性"URL",该属性将是文件的路径."WebArticle"也从"BaseArticle"继承和包括"FurtherInfo"属性和"标签"的对象,其中包括"身体",将持有要显示的HTML(Tab对象不从任何派生)的集合."新闻文章"和"JobArticle"继承自"WebArticle".我们有其他派生类,但这些提供了足够的示例.

我们提出了两种持久化修订控制的方法.我将这些称为"Approach1"和"Approach2".我使用SQL Server来做每个的基本图表:

使用Approach1,计划将通过数据库更新来保留新版本的文章.将为更新设置触发器,并将旧数据插入xxx_Versions表中.我认为需要在每个表上配置触发器.这种方法确实具有以下优点:每个文章的唯一"头部"版本保存在主表中,旧版本被放弃.这样可以轻松地将文章的头版本从开发/登台数据库复制到Live文件.

使用Approach2,计划将用于插入数据库的新版本的文章.文章的头版将通过视图确定.这似乎具有更少的表和更少的代码(例如,不是触发器)的优点.

请注意,使用这两种方法,计划是为映射到相关对象的表调用Upsert存储过程(我们必须记住处理添加新文章的情况).这个upsert存储过程将为它派生的类调用它,例如upsert_NewsArticle将调用upsert_WebArticle等.

我们正在使用SQL Server 2005,虽然我认为这个问题与数据库风格无关.我做了一些广泛的互联网拖网,并找到了两种方法的参考.但我没有发现任何比较两者的东西,并表明其中一个更好.我认为,对于世界上所有的数据库书籍,这种方法的选择必须先出现.

我的问题是:哪种方法最好,为什么？

Answer 1

一般来说，历史/审计边表的最大优势是性能：

• 查询的任何实时/活动数据都可以从更小的主表中查询

• 任何“仅实时”查询不需要包含活动/最新标志（或者上帝禁止在时间戳上执行相关子查询来查找最新行），从而简化了开发人员和数据库引擎优化器的代码。

然而，对于具有 100 或 1000 行（而不是数百万行）的小型 CMS，性能提升将非常小。

因此，对于小型 CMS，方法 3 会更好，因为设计更简单/代码更少/移动部件更少。

方法 3 几乎与方法 2 类似，只是每个需要历史记录/版本控制的表都有一个显式列，其中包含真/假“活动”（又名实时 - 又名最新）标志列。

您的 upsert 负责在插入行的新实时版本（或删除当前实时版本）时正确管理该列。

通过向任何查询添加“”，UPSERT 之外的所有“实时”选择查询都可以轻松修改AND mytable.live = 1。

另外，希望是显而易见的，但任何表上的任何索引都应以“活动”列开头，除非另有保证。

此方法结合了方法 2 的简单性（无需额外的表/触发器）和方法 1 的性能（无需在任何表上执行相关子查询来查找最新/当前行 - 您的更新插入通过活动标志来管理）