Firestore用户专属数据的合规NoSQL结构设计咨询

现有建模方案的问题 #

你当前设计的方案存在明显缺陷，后续使用会遇到以下问题：

• 单文档容量上限限制：Firestore单个文档最大仅支持1MB存储，若用户后续新增的分类数量较多，很容易触发大小限制导致写入失败
• 不支持原生查询：你无法通过Firestore的查询能力直接过滤指定type的分类、或对分类按名称排序，只能拉取整个用户文档后在本地遍历处理，既浪费带宽，性能也会随数据量增长快速下降
• 键名维护成本高：手动维护category_1、category_2这类键名极易出现冲突，尤其多端同步场景下，多个设备同时新增分类时大概率会出现数据覆盖问题
• 单条数据操作繁琐：修改、删除单个分类时，你必须先明确该分类对应的键名才能操作，额外增加了业务逻辑复杂度

推荐的用户专属数据建模方案 #

针对绝大多数用户专属数据的场景，最符合Firestore最佳实践的是用户子集合方案，结构设计如下：

# 根集合
users/
  # 每个用户对应一个文档，文档ID为用户UID
  {user_uid}/
    # 分类数据子集合
    categories/
      # 每个分类对应一个独立文档，文档ID使用Firestore自动生成的随机ID即可
      {category_id}/
        name: "groceries"
        type: "expense"

该方案的优势非常明显：

• 无存储容量限制：分类作为独立文档存储，用户可新增任意数量的分类，不会触发单文档上限
• 支持原生查询能力：可直接调用Firestore的查询接口实现分类过滤、排序、分页等操作，无需额外处理逻辑
• 操作逻辑简单：单条分类的增删改查都直接对应单个文档的操作，无需维护自定义键名，天然支持多端同步不会出现冲突
• 安全规则配置简单：直接匹配路径/users/{uid}/categories/{catId}，仅需校验request.auth.uid == uid即可完成权限控制，和你现有安全规则的适配成本极低

如果你的业务场景中每个用户的分类数量稳定不超过100条，也可以选择数组方案：在用户专属文档中新增categories数组字段，每个元素存储单条分类的完整信息。但该方案仍然存在单文档容量限制、不支持原生查询的问题，仅适合数据量极小的场景。

内容的提问来源于stack exchange，提问作者Dawid Sibiński