如何基于FirebaseFirestore高效实现产品心愿单Widget？

核心优化方向：避免低效关联与冗余查询 #

1. 用商品唯一ID替代名称做关联 #

• 不管采用哪种集合结构，永远存储Product的唯一ID（如productId）而非商品名称：
  • 商品名称可能重复，会导致关联错误；ID是数据库索引字段，查询速度远快于字符串匹配。
  • 示例Wish集合结构（同级设计）：

    {
      "userId": "user_a_123",
      "productId": "prod_456",
      "addedAt": "2024-05-20T10:00:00Z"
    }
    

  • 查询逻辑：先获取当前用户的所有productId，再用IN查询一次性从Product集合拉取所有对应商品，减少多次网络请求的开销。

2. 适度冗余常用展示字段 #

• 如果商品的核心展示信息（名称、价格、缩略图URL）不频繁更新，可以直接把这些字段存在Wish文档中：
  • 示例结构：

    {
      "userId": "user_a_123",
      "productId": "prod_456",
      "productName": "XX无线耳机",
      "price": 299,
      "thumbUrl": "https://xxx.com/thumb.jpg",
      "addedAt": "2024-05-20T10:00:00Z"
    }
    

  • 优势：查询Wish集合即可直接拿到渲染ListView所需的全部数据，无需再关联Product集合，大幅提升加载速度。
  • 注意：若商品信息更新，需通过数据库触发器（如Firebase Cloud Functions、MongoDB Change Streams）自动同步Wish中的冗余字段，避免数据不一致。

3. 优化集合结构：放弃嵌套，采用同级集合 #

• 原方案中User文档下嵌套Wish集合的设计，会增加查询层级（先定位User文档，再查子集合），在用户量较大时效率较低。
• 改用与Product同级的Wish集合，给userId创建单字段索引，查询用户心愿单时直接过滤userId，索引命中后查询速度极快。

4. 数据库端聚合查询，减少客户端逻辑 #

• 利用数据库的聚合能力（如MongoDB Aggregation、Firestore复合查询+关联），在数据库层面完成“查询用户心愿单+关联商品信息”的操作，客户端只需一次请求即可拿到最终数据：
  • 示例MongoDB聚合代码：

    db.wish.aggregate([
      // 过滤当前用户的心愿单
      { $match: { userId: "user_a_123" } },
      // 关联Product集合
      { $lookup: {
          from: "product",
          localField: "productId",
          foreignField: "_id",
          as: "productInfo"
        }
      },
      // 展开关联的商品数据
      { $unwind: "$productInfo" }
    ])
    

  • 优势：减少客户端的两次查询逻辑，降低网络延迟与代码复杂度。

内容的提问来源于stack exchange，提问作者강산들