娱乐历史

它往往有必要访问一些财产的历史价值。但有时，这一历史本身需要以追溯更新来修改。磅扑历史将时间视为两个维度：实际历史记录应该有哪些历史记录的信息完美传输，而记录历史记录捕获我们对历史的了解如何变化。

当我们想到一些财产（例如您的地址或薪水）随着时间的推移而变化时，我们通常将其视为线性变化序列。但令人惊讶的是，它经常比这种方式变得更加纠结，这种方式通常会混淆计算机化的记录。

我们正在为本公司处理薪资。我们于2月25日向我们公司运营薪资，我们的员工莎莉根据她每月薪水的6000美元支付。

3月15日，我们从人力资源部告诉我们，在2月15日，莎莉获得了6500美元的薪水。

那么我们应该在＆＃39;重新询问2月25日的莎莉和＃39;在一个意义上，我们应该回答6500美元，因为我们现在知道这是速度。但我们常常在25月25日忽略我们认为薪水是6000美元，毕竟是我们运行薪资的时候。我们打印了一张支票，送到她，她兑现了。这些都是基于她的工资的金额。如果税务机关于25日向我们征求薪水，这变得重要。

我发现我可以通过作为两个维度的时间来造成大部分这种纠结的意识 - 因此，“贝斯梅尔”一词。一个维度是莎莉的实际历史＆＃39; s薪水，我＆＃39; ll通过每个月的25日来说明，因为当工资记录运行时。

第二个维度出现在我们询问我们认为Sally＆＃39;薪资历史2月25日的思考是什么？ 2月25日，我们从人力资源部学获得了这封信，所以我们认为她的薪水总是6000美元。实际历史与我们的历史记录之间存在差异。我们可以通过向我们的表添加新日期来展示这一点

i＆＃39; m使用术语实际和记录历史的两个维度。您也可以听到有效的术语或有效（实际）和交易（记录）的人员。 [1]

我通过说出像＆＃34的东西读了这张表的行;在3月25日，我们认为Sally＆＃39; 2月25日的薪水是6500美元＆＃34;使用这种思维方式，我可以看看莎莉的早期表，并说实际的历史，并说它在3月25日＆＃39; s＆＃39; s的实际历史，如3月25日所知的实际历史。

在编程条款中，如果我想知道莎莉＆＃39;我没有历史，那么我可以用莎莉这样的东西。为了为（实际）历史为我需要使用sally.salaryat（＆＃39; 2021-02-25＆＃39;）。在一个磅扑座世界中，我需要另一个参数sally.salaryat（＆＃39; 2021-02-25＆＃39; 2021-03-25＆＃39;）

可视化这一点的另一种方法是制作一个曲线，其中x轴是实际时间，y轴是记录时间。我根据薪水水平遮蔽地区。 （图的形状是自从那里的三角形。我们没有试图记录未来的价值。[2]）

使用此图，我可以为25日的每次薪资进行实际历史如何发生变化的表格。我们看到2月25日的工资罗拉在莎莉没有提高的时候跑，但是当35月25日的工资筹码时，提升着名。

4月5日：抱歉我们之前的电子邮件中有一个拼写错误。 2月15日举办的莎莉＆＃39;筹集为6400美元。带来不便敬请谅解。

这是使天使哭泣的改变。但是当我们想到衡量纪念史的条款时，它并不难以理解。这里＆＃39;绘制了这个新的信息。

用于Payrols的水平线代表了记录时间的某个点的实际历史。 4月25日，我们知道Sally＆＃39;薪酬从2月15日从6000美元增加到6400美元。在那个角度来看，我们从未看到莎莉，因为它从未如此，我们从未看到过6500澳元。

这代表了我们对特定日期的价值的了解。表格表示2月25日的薪资，因为我们的知识随着时间的推移而变化。

当我们必须处理追溯变化时，符号历史是框架历史的有用方式。然而，我们不认为它经常使用它，部分原因是许多人不知道这项技术，还因为我们可以经常离开它。

一种避免它的方法是不支持追溯变化。如果您的保险公司在收到信中，任何变更都生效 - 那么＆＃39;策划实际时间匹配记录时间的方式。

当行动基于过去的状态时，追溯变更是一个问题，如追溯的状态，例如基于现在更新的薪资水平发出的薪资检查。如果我们只是录制历史记录，那么我们不必担心它追溯到它 - 我们基本上忽略了记录历史，只记录了实际历史。即使我们确实有不变动作，我们也可能会这样做，如果操作以这样的方式记录任何必要的输入数据。因此，莎莉的工资单可以在审计目的时颁发她的薪水。在这种情况下，我们只能逃脱她的工资的实际历史。然后将记录历史埋藏在她的工资单陈述中。

如果在发生行动之前进行任何追溯更改，我们也可能逃避实际历史。如果我们在2月24日学到了Sally＆＃39;在2月24日的薪酬变动，我们可以在薪资犯规行动依赖于不正确的图形之前调整她的记录而不达到。

如果我们可以避免使用符号历史，那么通常优选的是，因为它确实非常显着使系统复杂化。然而，当必须在实际和记录历史之间处理差异，通常是由于追溯更新，那么我们需要咬住子弹。其中最困难的部分是教育用户纪念碑历史如何工作。大多数人不会将历史记录视为改变的历史记录，更不用说记录的两个维度和实际历史。

在一个简单的世界中，历史只是申请。如果沟通是完美且瞬间的，每个感兴趣的演员都会立即学习所有新信息。然后，我们可以将历史视为我们添加到世界上的新事件发生的东西。

磅扑历史是一种方式来沟通沟通既不完美也不瞬间。实际历史不再是附加的，我们返回并进行追溯变化。但是记录历史本身仅是附加。我们不改变我们认为我们对Sally的想法＆＃39; S 2月25日的薪水。我们只是追加我们获得的后期知识。通过在实际历史记录中分层仅限份数记录历史记录，我们允许修改实际历史记录，同时创建其修改的可靠历史。

磅扑历史是一种机制，它允许我们跟踪价值如何变化，并且能够询问sally.salaryat（实际，recorddate）非常有帮助。但追溯变化不仅仅是调整历史记录。正如专家所说：“人们认为时间是严格的导致效应进步，但实际上来自非线性的非主观性的观点 - 它更像是一个诙谐的摇晃不断变化的威范大围的大球。” [3]如果我们应该支付6400美元的支付3000美元，那么我们需要达到60美元。至少意味着在后来的薪水中获得更多，但它也可能导致其他后果。也许较高的付款方式她应该在一个月前越过一些重要的门槛，也许有税收影响。

单独历史历史ISN＆＃39; t足以弄清楚这些依赖的效果，这需要一组附加机制，这些机制超出了这种模式的范围。一项措施是创建一个并行模型，它捕获了世界的状态，因为它应该具有正确的薪水，并用它来弄清楚补偿变化。 [4]衡量纪念历史可以为这些措施是有用的元素，但只有那个大球的一部分。

将历史添加到数据增加了复杂性。在一个磅扑座世界中，我需要两个日期参数来访问sally＆＃39; s raily.salaryat（＆＃39; 2021-02-25＆＃39; 2021-03-25＆＃39;）。我们可以简化默认值的访问，如果我们将默认值视为今天的记录时间，那么只需要当前记录时间的处理可以忽略衡量标复并发症。

但是，简化访问，并不一定简化存储。如果有任何客户需要符号数据，我们必须以某种方式存储它。虽然有一些数据库有内置支持的一些级别，但它们相对利基。在长寿的数据方面，人们倾向于是利基技术的超强。

鉴于这一点，通常最好的方法是提出自己的计划。有两种广泛的方法。

首先是使用磅声数据结构：将必要的日期信息编码到用于存储数据的数据结构中。这可以通过使用嵌套日期范围对象或关系表中的一对开始/结束日期来工作。

这允许访问所有的符号历史，但更新和查询难以尴尬 - 尽管通过使库句柄访问衡量标识信息可以更容易。

替代方案是使用事件采购。在这里，我们不要将莎莉的状态＆＃39;薪水作为我们的主要商店，而是将所有变化存储为事件。这些事件可能看起来像这样

请注意，如果事件需要支持符号历史，因此他们需要匹配。这意味着每个事件都需要在世界发生的事件发生时的实际日期（或时间），以及我们了解到的记录日期（或时间）。

存储事件在概念上更加直接，但需要更多处理来回答查询。然而，这种处理可以通过构建应用程序的快照和＃39; s状态的快照缓存。因此，如果此数据的大多数用户只需要当前的实际历史记录，那么我们可以构建一个只支持实际历史记录的数据结构，填充它从事件中填充它，并将其保持最新，因为新事件涓涓细流。那些想要磅声数据的用户可以创建一个更复杂的结构并从同一事件中填充它，但他们的复杂性不会让那些想要更简单的型号的人更难。 （如果有些人想在不同的记录日期看实际历史，他们可以使用几乎所有相同的代码来处理当前的实际历史。）

我遇到了1980年和＃39; s和90＆＃39; s和90＆＃39;我开始写下图案I＆＃39; D观察到，但在其他写作项目接管之前从未过过早草稿。在那里有讨论纪念碑史的讨论，我写了这篇文章来突出这个概念，希望能够更清楚地解释它。

此时Richard Snodgrass写了一本书：在SQL中开发以时代的数据库应用程序。它详细介绍了如何在SQL系统中使用这种问题，其方法影响了SQL：2011标准。

我从时间旅行中取出了透视的概念：改变的值的模式语言

有效时间和交易时间的术语来自Snodgrass，也是在SQL：2011标准中使用的。当我第一次开始向讲习班提供关于时间建模的研讨会，回到早期的鼻子时，我使用了这些术语，但人们发现他们混淆了。因此，我们开始使用实际/记录。由于有效/交易Hasn＆＃39; t成为广泛使用，我将遵循这一课并在此处使用实际/记录。

2：如果我们希望创作和记录预测，这可能是有用的

4：我开始在2000年代中期的并行模型上探索这个主题。我没有继续下去那条路，然后我不确定何时或何时何时或者在未来的踪迹中何时或＆＃39;

Alexandre Klaser，Dave Elliman，Joshua Taylor，Martha Rohte，Mauro Vilasi，Pavlo Kerestey，Pramod Sadalge，Rebecca Parsons和Saager Mhatre致力于在我们的内部邮寄列表中讨论本文。