牛津词典将“数据”定义为：“收集在一起的事实”。(注：世界是由事实组成的：维特根斯坦 )
如果我们改为使用应用程序架构师的专业语言，“数据”可以更准确地定义为：“折叠fold在一起的事件”。
“折叠”表示按时间顺序合并特定实体的（状态改变）事件以计算最新的实体“状态”
数据——与事件不同——是一个抽象概念。“事件”代表实体状态的实际变化（例如，PurchaseOrder.Deleted），“数据”仅代表特定实体的计算状态，一旦所有先前的事件都已折叠在一起；如果您丢失任何事件，甚至无法执行还原。
每当我听到诸如“数据是新的石油”之类的短语时，很明显我们仍然被困在存储受限的过去，因为应该清楚的是“事件是新数据”。
现在我们已经摆脱了以前存储限制的束缚，我们不再有任何逻辑、技术或财务理由来存储“数据”：我们应该只存储“事件”（毕竟，事件是所有数据）。我们应该在当今廉价而庞大的存储解决方案中持久化所有事件，并且应该只在需要计算给定实体（即“数据”）的“最后状态”或出于以下目的时才将事件“折叠”在一起。
仅保留事件，并将最近的事件折叠成一个高性能的内存中“实体查询存储”（EQS），将为我称为 DQRS 的东西提供高级支持：“Delta 查询责任分离”。使用这样的 DQRS 拓扑将确保“数据”可以直接从内存加载以进行初始数据加载——这意味着后端服务器上不收取任何费用——而任何新持久化的事件都将为增量检测提供本机支持：事件发生在客户端提供的 Delta-Query Timestamp (e-Tag) 之后，将有助于将完全读取限制为仅更新的实体——同样，直接来自内存 EQS。
Delta 和（实体）查询职责的这种分离将完全恢复我们持久模型的时间维度，因此也恢复到我们的分析工具和（未来）AI 算法。因此，我们今天真正应该讨论的是完全取代数据库的下一代“事件存储”，以及正确解释“内存是”这一事实的行业标准内存“实体查询存储”。新的存储'。“大数据”永远只能代表——大——“事件存储”的一小部分，所以让我们停止谈论数据（以及数据科学、数据架构师等）。
事件很重要，今天我们拥有实时存储和分析它们所需的一切，同时有效地满足离线移动应用程序不断增长的需求；1960 年代基于数据的模型无法正确支持某些东西（这正是 SAP在 SMP 3.0 中放弃客户端数据库“增量跟踪”的原因）。