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

去年，我们推出了一个致力于澳大利亚政治和twitter的网站

去年年底，我们的政客模式需要调整，因为一些政客退休了，新的政客加入了进来

更改数据库需要手动（SQL）更改，因此我考虑为管理员实现CMS，以便将来进行这些更改

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

我想想出一个集中的方法来做这件事

经过一段时间的思考后，也许最好的方法不是对政客数据的当前视图及其与政治制度的关系进行建模，而是对交易进行建模。这样，当前视图就是过去发生的所有事务/更改的投影

使用这种方法，其他站点可以“订阅”更改（一个lapubsub）并提交更改，只需将这些更改项集成到它们的模式中

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

我注意到有些东西是这样工作的——源代码版本控制、银行记录、stackoverflow points系统和许多其他示例

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

• 当前视图是否已缓存并重新加载？多久更新一次
• 什么样的基本实体必须存在，永远不会改变
• 可能现在我想不起还有更多

关于这个问题有没有值得推荐的文献？ 还有，像这样的数据建模模式或实践是否有用

非常感谢您的帮助

---

-CV

这是数据建模中相当常见的问题。基本上可以归结为：

您对当前视图、某个时间点的视图或两者都感兴趣吗？

例如，如果您有一个为订阅建模的服务，您需要知道：

• 某人在某个时间点有哪些服务：这是计算收费金额、查看帐户历史记录等所需的；及
• 某人现在有哪些服务：他们可以在网站上访问哪些服务

此类问题的出发点是要有一个历史记录表，例如：

• 服务历史记录：id、userid、serviceid、开始日期、结束日期

将用户的服务历史记录链接在一起，您就有了他们的历史记录。那么，你如何对他们现在拥有的东西进行建模？最简单的（也是最非规范化的视图）是说最后一条记录或具有空结束日期或当前或未来结束日期的记录就是它们现在拥有的

正如您所想象的，这可能会导致一些粗糙的SQL，因此这是有选择地反序列化的，因此您有一个服务表和另一个历史表。每次更改服务时，都会创建或更新历史记录。这种方法使历史记录表更像一个审计表（您将看到另一个术语）

这对你的问题很有帮助。你需要知道：

• 谁是众议院每个席位的现任议员
• 谁是每个席位的现任参议员
• 谁是各部门的现任部长
• 谁是首相

但你也需要知道在某个时间点，这些事情中的每一件是谁，所以你需要所有这些事情的历史

因此，2003年8月20日，Peter Costello发布了一份新闻稿，你需要知道，此时他：

• 希金斯的成员
• 司库；及
• 副总理

因为可以想象，有人可能对寻找彼得·科斯特洛（Peter Costello）或财务主管的所有新闻稿感兴趣，这将导致相同的新闻稿，但如果没有历史记录，就无法追踪

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

---

所有这些都不需要模式更改，因为模式应该能够处理它。

数据仓库体系结构中的更改跟踪技术有很好的技术（缓慢变化的维度）可以捕获此类内容。这样做的好处是，它在很大程度上使您的主要应用程序数据库处于孤立状态，缺点是进行追溯性更改更加困难，而且创建数据仓库显然需要大量的工作。如果人们对当前的历史记录不满意，并且希望通过一些数据输入追溯添加历史记录，或者经常需要对历史记录进行更正，那么您必须构建工具来删除这些信息。