如何在Firestore中建模多对多关系且不超出文档大小限制

当前采用任务文档内嵌tagIDs数组的方式存储任务与标签的多对多关系，受Firestore单文档1MiB存储上限约束，单任务持续新增关联标签时会超出大小限制；常规的中间关联表（junction table）方案需要在任务详情页额外查询关联关系，会拉高计费成本，以下是兼顾两类约束的可落地方案：

当前数据库结构 #

Firestore-root
    |
    --- tasks (collection)
    |     |
    |     --- taskID (document)
    |           |
    |           --- title: "Go for a cycle"
    |           |
    |           --- completed: false
    |           |
    |           --- userID: "zaEh95kXJKapyVUqrPws58dyRIC3"
    |           |
    |           --- tagIDs: ["rWqTxB01TK9w8KRo2GHD"]
    |           |
    |           --- // 其他任务属性
    |
    --- tags (collection)
          |
          --- tagID (document)
                |
                --- title: "Health"
                |
                --- userID: "zaEh95kXJKapyVUqrPws58dyRIC3"
                |
                --- colour: "red"
                |
                --- // 其他标签属性

分层混合建模方案（推荐） #

核心逻辑是拆分高频、低频场景，避开两种原生方案的短板：

• 保留内嵌数组的固定配额
  不删除task文档内的tagIDs字段，给这个字段设固定长度上限，比如单任务最多内嵌20个标签ID。按Firestore的存储开销计算，20个标准长度的文档ID仅占数百字节，距离1MiB的上限有充足余量，完全不会触发大小限制。
  绝大多数普通用户单任务关联的标签数不会超过20个，这类场景完全不需要额外查询，进入任务详情读取单条task文档即可拿到全部关联标签ID，查询成本和原有方案完全一致。
• 超量标签走任务子集合存储
  为每个task文档新增extra_tags子集合，当单任务关联标签数超过内嵌数组的配额时，超出的标签以单文档对应单标签的形式存入该子集合，每个子文档仅存储对应的tagID字段即可。
  这部分的额外查询成本极低：99%以上的普通用户不会触发超量逻辑，永远不需要访问这个子集合；仅在单任务关联标签量超标的极端场景下，才需要多发起一次子集合查询，这类场景占比极低，整体查询成本比全量走中间关联表低90%以上。
• 配套优化进一步压缩成本
  对单用户下的标签基础信息（标题、颜色等）做客户端本地缓存，标签是用户维度复用的数据，首次拉取后长期存在本地，后续不管是内嵌数组里的tagID还是子集合里的tagID，都直接从本地缓存匹配标签详情，不需要重复查询tags集合。
  写入逻辑做自动分流：新增标签关联时先检查内嵌tagIDs数组的长度，未达配额就写入数组，达到配额就自动写入extra_tags子集合；读取时先取内嵌数组数据，再补拉子集合数据做合并，前端展示层完全感知不到分层逻辑。

轻量场景备选方案 #

如果产品逻辑中单用户的总标签数不超过100个，可以直接把标签的核心信息（ID、标题、颜色）存在用户根文档下，所有任务的标签关联仅存储tagID，读取任务时直接从本地缓存的用户标签映射表匹配对应标签详情，不需要单独查询tags集合，成本更低。

相关参考 #

• 在Firestore中存储标签的最高效方式是什么？
• 如何在Firestore中建模多对多关系
• 什么是Firebase Cloud Firestore中的反范式建模（denormalization）？

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