从关系型数据转向事件
事件溯源的支持者认为，把每次变更都存成不可变事件流，可以保留业务历史、支持强大的分析能力，并解耦服务；但这串讨论里的许多工程师认为，它是一种被过度使用的、小众模式，往往只会增加复杂度，却没有明确收益。评论者强调，关系型数据库本来就支持时态和审计能力，而现实中大多数成功的“事件驱动”系统仍依赖传统 SQL 存储或投影来实现查询与一致性。逐渐形成的共识是：事件溯源在金融、分析或复杂工作流等特定领域很有价值，但并不适合作为取代基于 CRUD 的关系模型的默认方案。
关于这篇文章的总体看法
- 许多读者认为这篇文章不够清晰、过于自信，而且文风令人不适。
- 主要批评点：它暗示事件溯源应该“取代”CRUD/关系型方法，却没有严谨解释权衡、优缺点或具体迁移步骤。
- 也有人喜欢其总体方向（从事件/行为出发思考），但觉得这是一篇浅显或令人困惑的入门文。
事件溯源 vs 关系型/时态数据库
- 多位评论者强调，事件溯源和关系模型是正交的：你可以在 SQL 数据库之上实现事件溯源。
- 关系型数据库本就支持时态模式（例如审计表、日志、SQL:2011 特性）。
- 也有人提到 Datalog 及相关系统完全是关系型的，并且可以用于时态/事件式用法。
- 双时态问题也被提及：有些工具只跟踪事务时间，而不跟踪真正的“事件时间”。
被认为的优势 / 适用场景
- 被认为适合的场景包括：分析/日志、金融/日志式数据、复杂工作流、多系统同步、调试过去行为，以及能够重建或重新解释派生视图。
- 有人分享将事件溯源、DDD、CQRS、微服务以及投影结合到关系型/搜索存储中的成功经验。
- 另一些人则认为，对大多数产品来说，一个简单的关系型数据库加辅助历史表或审计日志就足够了。
批评、风险与失败案例
- 很多人认为事件溯源是小众且被过度使用的，常常是“找问题的解决方案”。
- 常见痛点包括：
- 在调试、将事件映射/归约为状态、维护以及模式演进方面复杂度很高。
- 聚合计算很慢，导致需要缓存/物化视图，并带来延迟和最终一致性问题。
- GDPR 和数据保留要求与不可变日志相冲突。
- 当“永不删除事件”遇上长生命周期时，存储和基础设施成本很高。
- 有一个详细的失败经历：一个 ES+CQRS 系统使用 Elasticsearch 投影、不允许删除、成本极高、导入极慢，而且只有少量用户——现在正在回退到更简单的 ACID 关系型设计。
讨论到的实现模式
- SQL 中典型的事件存储表结构包括：事件 id、聚合 id、序列/版本、类型、时间戳、JSONB 负载；按聚合以及有时按 JSON 字段建立索引。
- 使用快照来避免回放完整历史；将投影写入多个读模型（关系型、键值、搜索）。
- 有人主张把关系型数据库当作事件日志上的“缓存”；也有人反过来，只在以关系型为主的系统中增加事件表/审计日志。
- 对于工作流类问题，还提到了持久化工作流引擎（例如 Temporal/durable functions）作为替代方案，它们内部使用事件溯源。
元讨论：HN 投票动态
- 评论者指出，这篇帖子靠着大多负面的评论冲上了 HN 前列，原因被归结为标题驱动的点赞、提交内容不能点踩，以及人们为了让讨论保持可见而点赞。