Firestore中带分类的存储项最佳存储方式咨询

方案1：单集合 + Type属性 #

所有条目统一存放在同一个顶级集合（比如命名为items）中，每个条目文档新增type字段标注所属分类，文档结构示例：

{
  "name": "Egg",
  "type": "FoodItems",
  // 其他条目自定义字段
}

优势 #

• 开发成本极低，新增分类时直接给type字段赋新值即可，不需要提前创建任何分类相关的前置文档
• 查询灵活性高，全量条目查询、按分类筛选、跨分类统计等需求都可以直接实现，不需要额外处理多集合遍历逻辑
• 没有冗余资源消耗，不需要为无额外信息的分类创建无用空文档，符合Firebase按文档读写计费的成本优化逻辑

劣势 #

• 单集合条目量级超过10万时，按分类筛选的性能会略低于子集合方案，但小型项目完全感知不到差异
• 分类维度的精细化权限控制需要通过安全规则匹配type字段实现，复杂度略高于子集合方案

方案2：空分类文档挂载子集合 #

先创建顶级分类集合categories，每个分类对应集合下的一个空文档，再在每个分类文档下创建items子集合存放对应条目，数据路径示例：/categories/FoodItems/items/{条目ID}

优势 #

• 结构符合层级分类的直觉，后续如果需要给分类新增独立属性（比如分类排序权重、分类封面），直接在对应分类文档上加字段即可，不需要重构数据结构
• 分类维度的权限控制更简单，直接针对不同分类的子集合配置安全规则即可
• 单分类下条目量级极大时，查询性能优于单集合方案

劣势 #

• 维护成本更高，新增分类时必须先创建分类空文档才能写入对应条目，否则子集合创建会失败
• 跨分类查询需要使用集合组查询，全量统计、跨分类筛选的实现复杂度更高
• 对于无额外分类属性的小型项目属于过度设计，冗余操作没有实际价值

最终选型建议 #

你当前是小型项目，且明确分类本身不需要携带额外信息，优先选择方案1，开发效率高、维护成本低，完全可以覆盖现有需求。
如果后续需求迭代出现以下情况，再迁移到方案2也完全可行：

• 需要给分类增加独立的属性字段
• 单集合条目量突破10万级，按分类查询的延迟明显升高
• 需要针对不同分类做精细化的读写权限控制

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