如何建模数据规划
我想构建一个支持以下功能的数据模型：
数据历史记录 - 存储数据的每次更改。这不是问题： http://en.wikibooks.org/wiki/Java_Persistence/Advanced_Topics #History
数据规划 - 用户应该能够在将来的某个时间准备有效的记录（例如，我知道客户名称从五月份开始更改，所以我准备有效的记录 ）
我该怎么做第2点？
我怎样才能一起做这些事情（第 1 点和第 2 点）
I want to build a data model which supports:
Data history - store every change of data. This is not a problem: http://en.wikibooks.org/wiki/Java_Persistence/Advanced_Topics#History
Data planning - user should be able to prepare a record with validity sometime in the future (for example, I know that customer name changes from May so I prepare record with validity of 1st of May).
How can I do point 2?
How can I do these things together (points 1 & 2)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果你真的需要第 2 点 - 我会认真考虑这一点，因为根据我的经验，用户永远不会使用它，并且你将花费大量精力来支持没有人会使用的东西 - 无论如何，如果你真的需要那么：
直接在表中不进行任何更改。所有的变迁都会经历历史。
在幕后，您将定期运行批量更新程序。这会遍历历史记录，查找所有未应用的更改（在历史记录中设置状态标志以便能够快速找到它们），然后应用它们，并检查日期以确保是应用更改的时间。
您将不得不处理合并问题。如果用户说：一个月后我的名字发生了变化，该怎么办？然后进入 a 并更改其名称，即日起生效。你们有冲突。你如何解决它？您可以阻止任何立即更改，直到完成过去的更改（或者至少所有新更改的日期都晚于最后一次未应用的更改）。或者你可以现在改变，一个月后再改变。
If you really need point 2 - and I would think very hard about this, because in my experience users will never use it, and you will be spending a lot of effort to support something no one will ever use - anyway, if you really need it, then:
Make no changes at all directly in the table. All changes go through history.
Behind the scenes, periodically you will run a batch updater. This goes through history, finds all unapplied changes (set a status flag in the history to be able to rapidly find them), and applies them, and it checks the date to make sure it is time to apply the change.
You are going to have to deal with merges. What if the user says: In one month my name changes. Then goes in a and changes their name effective today. You have a conflict. How do you resolve it? You can either prevent any immediate changes, until past ones are done (or at least all new changes have a date after the last unapplied one). Or you can change it now, and change it again in a month.
我认为存储数据的变化是在后台处理的，研究一下数据仓库和缓慢变化的维度 http:// en.wikipedia.org/wiki/Slowly_changing_dimension 在存储过程中处理新记录和这些新记录的前身，这些记录将被称为“过期记录”。一旦您允许 SCD，就很容易找到您想要的那些历史过期记录。
I think storing the change of data is handled in the background, Look into data warehousing and slowly changing dimensions http://en.wikipedia.org/wiki/Slowly_changing_dimension in a Stored Procedure to handle new records and predecessors of those new records which will be known as "expired records". Once you allowed for SCD it's quite easy to find those historic expired records that you're after.