如何在Firestore数据库中为游戏Mode、Deck、Challenge关联场景建模

两种方案各有适用场景，你可以结合自己的业务需求选择： #

方案1：采用 Document Reference 实现关联 #

• 优势：
  • 适配Firestore原生能力，Flutter侧用cloud_firestore库开发时，可以直接对Reference字段调用get()方法拉取关联的Deck文档，不需要自己写编号匹配逻辑，开发效率更高，也避免了匹配逻辑出错的可能
  • 天然支持跨集合的事务、批量写入操作，后续如果有同时更新Mode关联的所有Deck、修改Deck后同步更新关联Challenge/Mode的需求，用Reference处理的逻辑更简单，也能更好的保证数据一致性
  • 不需要额外维护decknumber的全局唯一性，Firestore文档ID天然唯一，不会出现编号重复、冲突的问题
• 劣势：
  • 单独拉取Mode或Challenge列表时，无法直接拿到Deck的编号值，需要额外发起一次Deck文档的查询请求，会增加少量读成本
  • Reference存储的是完整的文档路径，比int类型的decknumber占用存储空间更大，但这个开销量级极低，基本可以忽略

方案2：新增decknumber整数字段实现关联 #

• 优势：
  • 读成本更低，查询Mode/Challenge列表时可以直接拿到decknumber值，不需要额外查询Deck文档，如果你大部分场景只需要展示Deck编号不需要Deck详情，这个方案的性能更好，也能节省读请求费用
  • 数值类型的筛选、排序效率更高，如果你经常需要按decknumber做范围查询、排序操作，整数字段的查询速度比Reference更快
  • 数据导出、跨平台迁移更方便，不需要处理Firestore特有的Reference类型，适配成本更低
• 劣势：
  • 你需要自行维护decknumber的全局唯一性，Deck数据量变大后很容易出现编号重复的问题
  • 关联查询需要自己实现匹配逻辑：先拿到decknumber，再去Deck集合查询对应文档，多了一层处理逻辑，增加了出bug的概率
  • 不支持Firestore原生的关联事务操作，跨文档的关联更新需要自己处理数据一致性问题

选型建议 #

如果后续业务会频繁做关联查询、跨文档事务操作，且没有强制要求decknumber全局唯一，优先选Document Reference方案，开发效率更高，数据一致性更有保障。
如果大部分场景只需要用到decknumber不需要Deck详情，对读成本敏感，且你能保证decknumber全局唯一，就选整数字段方案。
要是选整数字段方案，记得给Deck集合的decknumber字段加上单字段索引，能大幅提升查询效率。

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