Firebase Firestore用户数据结构咨询：当前设计是否合理？

你当前的结构确实存在优化空间，核心问题在于userinfo子集合仅存单个文档的设计完全没必要——这是受SQL分表思维的惯性影响，不符合Firestore这类文档型数据库的设计逻辑。

问题分析 #

Firestore的子集合是用来存储与主文档关联的多条同类型数据（比如用户的多个订单、多个地址），而用户基础信息（name、email）属于单份核心数据，单独用子集合存储只会增加读取次数（Firestore按文档读取计费）和查询复杂度，完全是冗余设计。

优化方案 #

根据你的业务场景，提供两种优化方向：

1. 单地址场景（用户只有一个地址）

直接将用户基础信息和地址字段合并到users集合的用户文档中，结构如下：

/users (collection)
  /userId1 (document)
    - name: "John Doe"
    - email: "john@example.com"
    - address: {
        street: "123 Main St",
        city: "Example City"
      }
  /userId2 (document)
    - name: "Jane Doe"
    - email: "jane@example.com"
    - address: {
        street: "456 Oak St",
        city: "Another City"
      }

这种设计的优势：

• 一次读取就能获取用户全部核心信息，节省成本
• 查询逻辑更直接，无需嵌套遍历子集合

2. 多地址场景（用户可能有多个地址）

如果用户需要存储多个地址（比如家庭地址、工作地址），保留addresses子集合是合理的，但仍需将用户基础信息合并到主文档中，同时建议给地址文档使用语义化ID（代替自动生成的ID），方便直接定位：

/users (collection)
  /userId1 (document)
    - name: "John Doe"
    - email: "john@example.com"
    /addresses (subcollection)
      /home (document)
        - street: "123 Main St"
        - city: "Example City"
        - type: "home"
      /work (document)
        - street: "789 Pine St"
        - city: "Work City"
        - type: "work"

核心设计思路总结 #

和SQL的“分表隔离”思维不同，Firestore的设计原则是把经常一起读取的数据放在同一个文档中，子集合仅用于存储主文档关联的多条同类数据。避免为单份数据创建子集合，既浪费资源又增加开发复杂度。

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