database - 历史数据建模文献、方法和技术

Question

去年我们推出了 http://tweetMp.org.au - 一个致力于澳大利亚政治和推特的网站。

去年年底，我们的政客架构需要调整，因为一些政客退休，新政客上任。

更改我们的数据库需要手动 (SQL) 更改，因此我正在考虑为我们的管理员实现 CMS 以在将来进行这些更改。

还有许多其他网站是澳大利亚的政府/政治网站，它们管理着自己的政客数据。

我想想出一个集中的方式来做到这一点。

考虑一段时间后，也许最好的方法是不对政客数据的当前 View 以及它们与政治系统的关系建模，而是对交易建模。这样当前 View 是过去发生的所有事务/更改的投影。

使用这种方法，其他站点可以“订阅”更改(la`pubsubhub)并提交更改，然后将这些更改项集成到他们的架构中。

如果没有这种方法，大多数站点将不得不拆除整个数据库并重新填充它，因此任何关联的记录都需要重新关联。以这种方式管理数据非常烦人，并且严重阻碍了为公共(public)利益整合这些数据。

我注意到有些事情是这样工作的——源版本控制、银行记录、stackoverflow 积分系统和许多其他示例。

当然，这种方法的直接挑战和设计问题包括

• 当前 View 是否已缓存并重新保留？它多久更新一次？
• 哪些基础实体必须存在且永不改变？
• 可能还有更多我现在想不起来的...

有没有任何人可以推荐关于这个主题的著名文献？此外，是否有任何有用的数据建模模式或实践？

非常感谢任何帮助。

-简历

Answer 1

这是数据建模中相当普遍的问题。基本上归结为:

您对现在的 View 、某个时间点的 View 或两者都感兴趣吗？

例如，如果您有一项为订阅建模的服务，您需要了解:

• 某人在某个时间点有哪些服务:计算收费金额、查看帐户历史记录等都需要此信息；和
• 某人现在拥有哪些服务:他们可以在网站上访问哪些内容？

这类问题的出发点是有一个历史表，比如:

• 服务历史:id、userid、serviceid、start_date、end_date

将用户的服务历史链接在一起，您就拥有了他们的历史。那么你如何模拟他们现在拥有的东西呢？最简单(也是最非规范化的观点)是说最后一条记录或带有 NULL 结束日期或当前或 future 结束日期的记录是他们现在拥有的。

正如您所想象的那样，这会导致一些粗糙的 SQL，因此它被选择性地去规范化，因此您有一个服务表和另一个用于历史记录的表。每次更改服务时，都会创建或更新历史记录。这种方法使历史表更像是一个审计表(您会看到另一个术语)。

这与您的问题类似。你需要知道:

• 谁是众议院每个席位的现任议员；
• 每个席位的现任参议员是谁；
• 每个部门的现任部长是谁；
• 谁是总理。

但是您还需要知道在某个时间点这些事物中的每一个是谁，因此您需要所有这些事物的历史记录。

所以在 2003 年 8 月 20 日，Peter Costello 发表了一篇新闻稿，你需要知道他当时是:

• 希金斯议员；
• 财务主管；和
• 副总理。

因为可以想象，有人可能会对查找 Peter Costello 或财务主管发布的所有新闻稿感兴趣，这将导致相同的新闻稿，但如果没有历史记录将无法追踪。

此外，您可能需要知道哪些席位位于哪些州，可能还有地理边界等等。

这些都不需要更改架构，因为架构应该能够处理它。