Firestore文档引用选型：SHA256唯一ID与原生成字段该选哪一个？

方案分析 #

仅存SHA256 ID #

• 优势：严格遵循NoSQL「单一数据源」核心原则，所有关联关系依赖唯一、稳定的SHA256 ID，从根源上避免数据不一致问题；完全匹配你重构数据库统一ID的目标，架构更清晰。
• 劣势：获取可读字段（如司机姓名）需要额外查询关联文档，但这个开销可通过多种手段优化：
  • 前端使用批量读取API（如Promise.all配合doc().get()）一次性拉取多个关联文档；
  • 利用Firestore本地缓存机制，重复访问时无需重复请求；
  • 若场景允许，可在后端通过Cloud Functions预生成包含关联字段的聚合文档（如trucks_with_driver_info集合），前端直接读取聚合数据。

仅存原始唯一字段 #

• 优势：无需额外查询，前端可直接读取可读值，渲染逻辑更简单。
• 劣势：这是NoSQL设计的高危操作——违反「单一数据源」原则。一旦原始字段（如司机姓名）需要修改，你必须遍历所有引用它的文档逐一更新，数据量增大后这个操作不仅耗时耗力，还极易出现遗漏，导致数据不一致，后期维护成本极高。即使原始字段当前是唯一的，也无法保证未来不会出现修改需求，风险不可控。

两者都存（冗余存储+Cloud Functions同步） #

• 优势：兼顾了关联关系的稳定性（SHA256 ID）和可读字段的便捷性，前端可直接使用冗余的可读值，同时保留ID用于可靠的关联操作。
• 劣势：大幅增加架构复杂度，需要编写并维护Cloud Functions监听被引用文档的修改事件，同步更新所有关联文档；高频修改场景下会增加Firestore的调用成本和延迟，且Function执行失败时可能出现数据不一致，需要额外的错误重试和补偿机制。

推荐方案 #

优先选择仅存SHA256 ID，这是最符合Firestore设计范式、长期维护成本最低的方案。只有当你通过实际性能测试确认额外查询的开销已经影响用户体验，且被引用字段的修改频率极低时，再考虑两者都存的冗余方案。绝对不推荐仅存原始唯一字段的方案。

内容的提问来源于stack exchange，提问作者Emi Buliga