Firestore关联文档：保存文档引用还是文档ID？

核心区别 #

• 存储本质
  • 文档ID：就是纯字符串/数字类型的唯一标识，比如user_001，本质是目标文档的“门牌号”，不带任何额外上下文信息，完全依赖业务代码明确它所属的集合/数据库。
  • 文档引用：是部分数据库提供的专用结构化类型（比如MongoDB的DBRef、Firebase的DocumentReference），除了包含目标文档ID，还打包了集合名、数据库名等信息，相当于带了“街道+门牌号”的完整地址。
• 查询操作
  • 文档ID：查询关联数据时需要手动指定集合，比如db.articles.find({author_id: "user_001"})，步骤直观但多一步手动关联，不过纯基础类型的索引优化简单，性能开销极低。
  • 文档引用：支持数据库原生关联查询，比如MongoDB中用$lookup可直接通过DBRef自动匹配对应集合的文档，无需手动指定集合，但因为是复杂类型，索引创建和查询解析的开销略高，部分数据库对引用的索引支持不如纯ID灵活。
• 耦合与迁移
  • 文档ID：若目标文档迁移到其他集合，ID本身不变，但查询代码必须同步修改集合名，耦合点在代码层。
  • 文档引用：因自带集合/数据库信息，只要更新引用本身，查询代码无需改动，耦合点在数据层，但如果引用未同步更新，会出现无效关联的问题。
• 数据完整性
  • 文档ID：数据库不会自动校验ID是否存在，需在业务代码中添加存在性检查，或通过触发器、约束实现，否则易出现指向已删除文档的“死ID”。
  • 文档引用：部分数据库自带引用完整性校验，比如删除目标文档时自动清理关联引用，或阻止删除被引用的文档，能减少无效关联，但并非所有数据库都支持该特性。

场景选择建议 #

• 优先选文档ID的情况
  • 使用轻量型文档数据库，或团队希望避免依赖数据库特殊特性，保持代码通用性。
  • 关联关系固定，比如用户与文章始终在同一数据库的固定集合中，无迁移需求。
  • 高并发场景，对查询性能要求极高，纯ID的索引和查询开销更小。
• 优先选文档引用的情况
  • 关联关系复杂，比如同一ID可能存在于多个集合，或目标文档可能跨集合/数据库迁移，需要引用自带上下文信息。
  • 希望减少业务代码校验逻辑，由数据库自动维护数据完整性，比如删除用户时自动清理所有关联订单引用。
  • 团队统一使用数据库原生关联特性，追求开发效率，不想手动编写关联查询代码。

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