5

我很快就会开始一个项目的工作，这个项目（从规范中）让我想起了 StackOverflow。基本上，它是一个具有用户控制内容的网络应用程序。

让我在脑海中转圈圈的功能之一是版本控制。在 StackOverflow 上，每个问题和答案都可以有多个修订。当您只有一种类型的对象（在这种情况下，还有它的文本）时，这很容易实现。

所以，对于我的简单页面，我已经准备好了。

当我认为某些需要受版本控制的对象具有关系时，问题就出现了。为了提供一个具体的例子，让我选择一个随机的类比域：

假设我正在实施一个类似 Wiki 的网站来跟踪书籍/作者信息。该站点的主要重点是创建和更新“作者”页面，作为文本，这些页面非常简单（如上所述）。然而，让我们在作者和书籍之间添加一个一对多的关联（换句话说，书籍将是单独的对象，因为显然一个人可以编写许多书籍）。每本书都有一个从作者页面到关于该书的信息页面的链接。

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

当这种关系变成多对多时，这变得更加复杂，其中可以将多个作者列为对一本书做出贡献。

我有很多解决方案，但没有一个像我想要的那样干净（并且至少涉及一些重复的代码/冗余数据存储），虽然我确实在这里看到了共性，但我觉得我还没有真正能够最好地提取它，尤其是在数据库级别。我不想对给出的答案产生偏见，所以我不会马上给出。

那么，您将如何在数据库级别设计该系统？我在这里寻找表格规范，如果不是很明显的话，可能还有你如何使用它们的描述。对于那些可能相关的答案，我将使用 ASP.NET 和 Linq-to-SQL（我对 LTS 中的多对多感到满意）或实体框架。

编辑：澄清一下，我了解基本的数据库设计、规范化、多对多映射表等。我正在为这种特定情况寻找一个干净的解决方案。

编辑2：我正在寻找一个通用的解决方案，因为系统中可能有更多的子对象而不仅仅是书籍。作者可能与其他作者、杂志、事件等有关。如果我为每个作者单独实现历史，我觉得我正在重复很多工作。

4

3 回答 3

5

这是数据仓库中的一个常见问题。他们使用“缓慢变化的维度”。

但是，如果您要尝试使用“版本化”数据，则必须有一些规则。

  1. 您必须按照最初定义的方式记录 Author-Book 关系。这是官方的作者-书籍关系。这是数据仓库人员所说的“无事实事实表”。是一对钥匙。

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

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

请注意，关系（作者与书籍）是事实，不需要版本。这是事实。它不会“改变”。它要么是真的，要么是错误地放入数据库中——在这种情况下，它必须被删除。事实不需要版本号。

在更复杂的星型模式中，您的事实有衡量标准。价格、销售量、成本、利润等。这些也记录在事实表中。这些信息可能会随时间而变化。因此，您几乎总是对每个事实都有一个时间维度。

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

时间维度与版本号并不完全相同。它稍微简单一些。它指出，在给定的时间点，事实是真实的。如果事实发生变化，您将附加一个具有不同时间戳的新事实。

您可以在给定的特定时间点找到相关事实和关联的维度值。

于 2009-08-17T02:32:18.610 回答
1

我为每个表都有一个表：即作者和书。

表之间存在通常的外键关系（无论是什么）。

每个表还有一个历史表，即 AuthorHistory 和 BookHistory。这些历史记录表包含旧的/过时版本的记录（例如，每个已删除和/或编辑的作者记录）。与历史表没有外键关系。

编辑：

每个表的某些功能都是相似的：例如，无论是哪个表，更新记录都意味着将记录的旧副本存储在相应的历史表中。我使用数据库触发器（每个表的更新和删除触发器）来实现此功能；因为我使用的数据库引擎支持触发器，这使得它对应用程序透明。这些触发器中的代码从一个表到下一个表是相似的（只有表的名称和字段名称列表，从一个表到下一个表不同）。

多对多的情况呢？这更加困难，因为您实际上可能没有将作者映射到一本书的记录，但以前有一个记录并且需要将其显示为历史项目

编辑#2：

我还没有实现多对多情况的历史，但我不明白为什么它会不一样，即：

  • 多对多关系是通过有一个 BookAuthor 表来实现的，每个表的记录就是 BookId 加上 AuthorId。
  • 历史关系位于对应的 BookAuthorHistory 表中。
于 2009-08-16T22:18:38.683 回答
1

听起来几乎是 CouchDB 的理想用例。使用这个面向文档的数据库，您可以免费获得修订（除非您配置不同的数据库，否则每个文档都会自动修订）。

文档之间也可以有 m:n 关系。但是，迁移到 CouchDB 是相当大的一步，我不知道从 ASP.NET 访问它的效果如何。但是阅读一些介绍性教程不会受到伤害。

于 2009-08-17T11:17:39.470 回答