去年我们推出了http://tweetMp.org.au - 一个致力于澳大利亚政治和推特的网站。
去年年底，我们的政治家架构需要调整，因为一些政治家已经退休，新的政治家也进来了。
更改我们的数据库需要手动（SQL）更改，因此我考虑为管理员实施CMS以便将来进行这些更改。
还有许多其他网站，政府/政治网站为澳大利亚管理他们自己的政客数据。
我想提出一种集中的方式来做到这一点。
在考虑了一段时间之后，也许最好的方法是不对政治家数据的当前观点及其与政治制度的关系进行建模，而是对交易进行建模。这样当前视图是对过去发生的所有交易/变化的预测。
使用这种方法，其他网站可以“订阅”更改（la`pubsubhub）并提交更改，并将这些更改项集成到他们的模式中。
如果没有这种方法，大多数站点都必须拆除整个数据库，并重新填充它，因此任何相关的记录都需要重新关联。以这种方式管理数据非常烦人，并且严重阻碍了这些数据的混搭以供公众利益。
我注意到一些事情就是这样 - 源版本控制，银行记录，stackoverflow点系统和许多其他例子。
当然，这种方法的直接挑战和设计问题包括
是否有任何人可以推荐的有关此主题的着名文献？ 此外，这样的数据建模的任何模式或实践都可能有用吗？
非常感谢任何帮助。
-CV
答案 0 :(得分：2)
这是数据建模中相当常见的问题。基本上它归结为：
你对现在，某个时间点或两者的观点感兴趣吗？
例如，如果您有一个需要知道的订阅模型的服务：
此类问题的出发点是拥有一个历史表，例如：
将用户的服务历史链接在一起，您就拥有了他们的历史。那么你如何模拟他们现在拥有的东西呢？最简单（也是最非规范化的视图）是说最后一条记录或具有NULL结束日期或现在或将来结束日期的记录是他们现在拥有的。
正如您可以想象的那样，这可能会导致一些粗糙的SQL，因此这是有选择性的非文明化，因此您有一个Services表和另一个历史表。每次更改服务时，都会创建或更新历史记录。这种方法使历史表更像是一个审计表（另一个你会看到的术语）。
这与您的问题类似。你需要知道：
但是你还需要知道某个时间点上每个人是谁，所以你需要有所有这些事情的历史记录。
因此，在2003年8月20日，彼得科斯特洛发布了一份新闻稿，你需要知道他此时是：
因为可以想象有人可能会有兴趣找到彼得科斯特洛或财务主管的所有新闻稿，这将导致相同的新闻稿，但如果没有历史记录将无法追踪。
此外，您可能需要知道哪些座位处于哪些状态，可能还有地理边界等等。
这些都不需要架构更改，因为架构应该能够处理它。