我们绝对可以将人类的整个历史视为事件的链条：
微小的事件，大事件，大事件，关键事件 - 其中一些是可以忽略不计的，相反，有些是链条中的下一个链接，并改变了我们的世界的外观。

但是，我们挖掘出历史的细节越多，我们擦除的斑点越多，我们看到的东西就越令人惊讶，甚至矛盾的事物 - 有时可以完全反驳我们的观点和假设。我们认为和认为是事实的事情可能会被无效 - 我们需要改变过去。

每种记录系统都不完美，并且可能包含错误。但是，如果我们想构建一个对此类错误有弹性的系统怎么办？如果我们想改变过去，但要将历史记录为事实怎么办？

更新到位

在几乎所有计算机和计算机科学的存在中，资源都是最大的限制，也是最复杂的问题之一。

我们的进度使我们能够从字节转换为千字节，从千数到大型和千兆字节。现代PC，智能手机和云系统可以轻松处理几乎无限的数据。

存储在计算机时代开始时在身体上是巨大的，从设备接管大厅和房间，转移到CD，软盘和硬盘驱动器上，以便我们可以甚至在我们的口袋里携带电影，大量的照片和音乐。该存储似乎总是是问题，在构建软件方面，这是我们最小的头痛。

尽管如此，我们从计算机时代的曙光中继承了习惯（坏>）仍然存在，可以说是最大的开发人员的头痛之一 - 。在存储容量的进度之前，我们非常谨慎地对我们如何消耗RAM和磁盘空间，这迫使我们突变变量和数据，而不是以不可变的方式持续存在，即保存新记录，而不是更新现有的现有记录一个。

即使功能性编程语言和the immutability approach正在上升，我们仍然困扰着我们是建造的。

审核系统

如何使用常见的可突变DB设计记录跟踪系统？可以说我们使用PostgreSQL并定义一个简单的audits表：

然而，一个半月前，我们发现麦克斯忘了写下Bullsheepinc的记录，并且由于专栏的默认为0，我们在相当长的一段时间内没有意识到这一变化。现在，如果我们想修复它，我们必须覆盖现有记录：

这种方法的缺点清晰可见：我们对变化失去了追踪，忘记了错误。正如我们的报告已经发送的那样，不会对Bullsheepinc受到任何惩罚。

时间性

从Mutability到我们设计完美记录系统的目标的下一步将是持续变化作为事实，而不是更新到位的数据。
为了构建一个真正不变的系统，我们希望在审计系统中禁止覆盖记录。相反，我们将将任何类型的数据更改存储为a
数据库中的单独行：

看起来这个选项对我们来说更好。现在，我们看到库存记录更改已被跟踪，我们实际上发现了一些问题。
我们可以在那里停下来，假装我们建立了最先进的审计系统，但这离真相太远了，我们很快就得到了另一个请求。

追溯变化

一旦我们的员工开始看到审计记录，而且还可以查看数据修复，约翰回忆说，实际上是他进行了计数，而发现的问题的数量实际上是 99 而不是 101 。
我们现在有一个严重的问题，因为新记录不适合我们的数据模型：

现在哪个记录确实有效？我们应该信任麦克斯还是约翰？我们应该如何定义错误和如何纠正？

咬时

在上面的示例中，我们只有一个时间列：记录或交易日期。
BITEMSTOMAITY假设添加了另一个时间维度 - 所谓的有效时间或有效的时间 - 沿交易时间用于跟踪时，当更改确实发生了 /strong>。

    module Audit
      # @returns [Hash] a hash with auditor, issues found and transaction date fields
      def get_record(company, valid_date = nil, transaction_date = nil)
        # calling the DB ...
      end
    end

    > Audit.get_record("BullSheepInc")
    # {auditor: "John", issues_found: 99, transaction_date: "01.05.2022"}
    > Audit.get_record("BullSheepInc", "15.09.2021")
    # {auditor: "Joe", issues_found: 180, transaction_date: "15.09.2021"}
    > Audit.get_record("BullSheepInc", "01.01.2021")
    # nil - we didn't inspect the company as of 01.01.2021
    > Audit.get_record("BullSheepInc", "15.02.2022", "01.04.2022")
    # {auditor: "Max", issues_found: 101, transaction_date: "01.04.2022"}