代码之家 › 专栏 › 技术社区 › CVertex

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

pubsubhubbub datamodel data-modeling database

CVertex · 技术社区 · 15 年前

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

去年年底,我们的政治家模式需要调整,因为一些政治家退休了,新的政治家出现了。

更改数据库需要手动(SQL)更改,所以我正在考虑为管理员实现一个CMS,以便将来进行这些更改。

还有许多其他的网站,政府/政治网站在那里为澳大利亚管理自己的政治家数据。

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

经过一段时间的思考,也许最好的方法是不要对政治家数据的当前观点以及它们与政治系统的关系进行建模,而是对交易进行建模。这样,当前视图就是对过去发生的所有事务/更改的投影。

使用这种方法,其他站点可以“订阅”更改(la`pubsubub),提交更改,并将这些更改项集成到它们的模式中。

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

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

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

关于这个问题有什么值得推荐的文献吗? 此外,像这样的数据建模模式或实践是否有用?

非常感谢您的帮助。

-CV

1 回复 | 直到 15 年前

cletus 15 年前

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

你对这景色感兴趣吗现在在某个时间点的观点,还是两者兼而有之?

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

这种问题的起点是要有一个历史表,例如:

将用户的服务历史链接在一起,您就有了他们的历史。那么,你如何模拟他们现在拥有的东西呢?最简单(也是最不规范化的视图)是说,最后一条记录或结束日期为空或当前或未来结束日期的记录就是它们现在拥有的。

正如您可以想象的那样,这会导致一些粗糙的SQL,所以这是选择性地去噪的,所以您有一个服务表和另一个历史表。每次更改服务时,都会创建或更新历史记录。这种方法使历史表更像是 审计表 (你将看到另一个词)。

这是对你的问题的分析。你需要知道:

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

因此,2003年8月20日,彼得·科斯特洛发布了一份新闻稿,你需要知道,此时他:

因为可以想见,有人可能对彼得·科斯特洛或财务主管的所有新闻稿都感兴趣,这将导致相同的新闻稿,但如果没有历史,将无法追溯。

此外,您可能需要知道哪些座位在哪个州,可能是地理边界等等。

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