在Firebase中存储数据以实现最优读取与统计应用的方案咨询

餐食类型存储方案选择 #

你可以根据业务扩展需求三选一，优先推荐Map方案适配当前场景：

• 单独存储为文档：仅适合餐食类型需要挂载大量附加属性的场景，比如后续要给每种类型加独立抵扣规则、热量阈值、适用门店等配置，且类型总量超过20种。可以单独建立meal_types集合，每个类型对应一个文档，用户选择后仅在消费记录中存储关联的类型ID即可。如果没有上述附加属性需求，该方案过重，不推荐。
• 数组存储：仅适合单条消费记录允许多选餐食类型、且无高频统计需求的场景，直接在消费记录中加selected_types: ["素食","鱼类"]字段即可，优点是写入逻辑简单，缺点是聚合统计时分组查询效率低。
• Map存储：适配你当前的统计需求，是最推荐的方案。Map的键为固定的餐食类型枚举，值为布尔值/数值标记是否选中，示例结构：

  selected_meal_types: {
    素食: true,
    汤品: false,
    沙拉: false,
    鱼类: true,
    肉类: false
  }
  

  该结构后续做聚合查询时可以直接匹配对应键的状态，统计效率远高于数组，且写入逻辑复杂度低。

周/月餐食统计实现建议 #

优先推荐增量预计算方案，性能和成本最优：

• 新建独立的user_meal_stats集合，按「用户+统计周期」为维度存储单条统计文档，文档ID可以设计为{user_id}_{year}_{month}（月度统计）或{user_id}_{year}_w{week_number}（周度统计），文档结构示例：

  {
    uid: "用户唯一ID",
    period: "2024-06", // 统计周期标识
    type_count: {
      素食: 4,
      鱼类: 2,
      肉类: 6
    },
    update_time: 1717238400000 // 最后更新时间戳
  }
  

• 给存储用户抵扣券消费记录的集合配置Firebase Cloud Function的onCreate触发器，每次用户新增一条有效消费记录时，自动累加该用户当前周、当前月统计文档中对应餐食类型的计数。如果后续支持用户修改/删除历史消费记录，额外配置onUpdate、onDelete触发器同步更新统计数值即可。
• 如果你的项目用户量极小、单用户月度消费记录不超过1000条，也可以直接用Firestore原生聚合查询，每次统计时筛选对应用户、对应时间范围的消费记录做实时累加，无需额外维护统计集合，但数据量上涨后查询成本和延迟都会明显升高。

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