我开始了ES之旅并想知道传统支持表是否应该存储在事件日志中，还是应该以不同方式处理？这些表通常具有CRUD页面。换句话说，在同一个应用程序中有两种方法是常见的，一种用于支持表，一种用于事务数据？
支持表就像＆＃34;帐户＆＃34;在会计应用程序中或＆＃34;产品类型＆＃34;或实际＆＃34;产品＆＃34; ERP应用程序中的表格（我没有编写ERP应用程序 - 这是我所谈论的表格类型的一个例子）。
如果我们在事件日志中存储CRUD类型的数据，那么我们可能会有事件：
然后，我们是否尝试找出更改的内容（在ProductUpdated事件中）并只存储更改和重播以获取产品的最新图像？
大多数情况下，我是在使用什么方法来使用CRUD表 - 传统或存储在事件日志中？其他信息会很棒！
答案 0 :(得分：1)
假设您完全使用事件日志，包括select()等事件，而不是其他数据存储。然后会发生的是，每次应用程序启动时，它都必须重播所有日志中的事件以构建其当前状态。
现在，假设您创建了一个传统的SQL表来存储应用程序的当前状态（比如ProductCreated表）以及为了达到该状态而处理的最后一个事件的ID （比如products表）。然后，每当您的应用启动时，它必须重播仅 ID高于存储ID的事件，并处理这些事件以构建其新状态。
另一方面，您的应用现在必须小心保持这两个状态同步。如果您需要并发，那么您需要小心只在SQL表上执行原子操作 - 但这对于事务来说应该相当容易。
答案 1 :(得分：1)
您的支持表只是事件流的读取模型/投影。一般而言，如果您需要，您不会创建这些支持模型。只有在UI。
无论如何，Event sourcing背后的一个重要好处是您不需要在查询中使用join。也就是说，为每个table创建一个read-model，其中包含所需的所有数据 - 完全非规范化。您保持该表针对查询进行了超级优化。