实现DB对象的版本控制

Question

我很快就会开始研究一个项目(从规范中)让我想起StackOverflow.基本上,它是一个具有用户控制内容的Web应用程序.

让我在脑海里转转的一个功能是版本控制.在StackOverflow上,每个问题和答案都可以有多个修订版.当你只有一种类型的对象(在这种情况下,它的文本)时,这很容易实现.

所以,对于我的简单页面,我已经设置好了.

当我认为某些需要在版本控制下的对象具有关系时,问题就出现了.为了提供一个具体的例子,让我选择一个随机的analagous域:

让我们说我正在实施一个类似Wiki的网站来跟踪书籍/作者信息.该网站的主要焦点是创建和更新"作者"页面,这些页面作为文本非常简单(如上所述).但是,让我们在作者和书籍之间添加一对多的关联(换句话说,书籍将是单独的对象,显然一个人可以创作许多书籍).每本书都有一个从作者页面到关于该书的信息页面的链接.

对于用户来说,描述作者的基于文本的"摘要"与该作者及其作品之间的链接之间几乎没有区别.因此,我们需要为作者页面,书页以及作者和书籍之间的关联实现"修订"/编辑功能.换句话说,用户应该能够编辑,查看历史记录和回滚作者页面,书页以及两者之间的关联.

当这种关系变成多对多时,这变得更加复杂,多个作者可能被列为对书籍的贡献.

我有很多解决方案,但没有一个像我想的那样干净(并且至少涉及一些重复的代码/冗余数据存储),虽然我确实看到了这里的共性,但我觉得我真的无法提取它,特别是在数据库级别.我不想偏袒给出的答案,所以我不打算立刻给他们.

那么,您将如何在数据库级别设计此系统？我在这里寻找表格规格,并且可能描述了如何使用它们,如果不是立即显而易见的话.对于那些可能相关的答案,我将使用ASP.NET和Linq-to-SQL(我很熟悉LTS中的多对多)或实体框架.

编辑:为了澄清,我理解基本的数据库设计,规范化,多对多映射表等.我正在寻找一个干净的解决方案,以满足这种特定情况.

编辑2:我正在寻找一个可推广的解决方案,因为系统中可能有更多的子对象而不仅仅是书籍.作者可能与其他作者,杂志,事件等等有关.如果我为每个作者单独实施历史记录,我觉得我正在重复很多工作.

Answer 1

这是数据仓库中常见的问题.他们使用"缓慢变化的维度".

但是,如果您要尝试使用"版本化"数据,则必须有一些规则.

1. 您必须记录最初定义的作者 - 书籍关系.这是官方的作者 - 书籍关系.数据仓库人员称之为"无事实的事实表".这是一对钥匙.

2. 书籍是书籍作者事实的一个方面.这本书可以改变.有许多缓慢变化的维度算法.您只能保留最新的历史表,与当前表分开.将历史记录和当前值保存在一个带有标记的表中,以区分当前历史记录.

3. 作者是书籍作者事实的一个维度.作者可以改变.同样,有许多SCD算法.继续阅读选择.通过Ralph Kimball的数据仓库工具包获取更多信息.

请注意,关系(作者预订)是一个事实,不需要版本.这是事实.它没有"改变".这是真的,或者它被错误地放在数据库中 - 在这种情况下,必须将其删除.事实不需要版本号.

在更复杂的星型模式中,您的事实有措施.价格,销售量,成本,利润等.这些也记录在事实表中.这些信息可能会随时间而变化.因此,您几乎每个事实都有一个时间维度.

因此,时间是书籍作者事实的一个维度.如果这个事实可以改变,则适用的时间段被记录为事实的一部分.

时间维度与版本号不完全相同.它稍微简单一些.它指出,在某一特定时间点,事实确实如此.如果事实发生变化,您会添加一个具有不同时间戳的新事实.

在特定时间点,您可以找到相关事实和相关维度值.