对于当前的数据结构，您确实必须采取两步走的方法:

With your current data structure you will indeed have to do the two-stepped approach:

1. 加载组 ID 列表
2. 加载每个组的元数据(例如名称)

这被称为客户端连接，在Firebase中很常见.

This is known as a client-side join and is quite common with Firebase.

或者，您可以在每个用户的组下复制有关每个组的最重要的信息.例如

Alternatively you can duplicate the most important information about each group under each user's groups. E.g.

UserGroups
  User1
    Group1: "This is the first group"
    Group2: "This is the second group"

正如您在此示例中所看到的，我们已将 true 标记替换为该组的实际名称.这样做的好处是，对于一个简单的用例，您只需要阅读此列表，而无需执行客户端联接.缺点是您需要确定是否/如何保持数据同步.我在此处为此选项写了一个答案:如何在Firebase中编写非规范化数据

As you see in this sample we've replace the true marker with the actual name of the group. The advantage of this is that for a simple use-case you only have to read this list and not do a client-side join. A disadvantage is that you need to decide whether/how to keep the data sync. I wrote an answer with the option for that here: How to write denormalized data in Firebase

请注意，由于您要混合实体类型，因此数据模型没有完全展平.我建议从用户所属的组列表"中拆分每个用户的元数据(其名称和描述).剩下四个***列表:

Note that your data model is not fully flattened, since you're mixing entity types. I recommend splitting the metadata of each user (their name and description) from the "list of groups that the user belongs to". That leaves you with four top-level lists:

Users
Groups
UserGroups
GroupUsers

这是多对多关系的常见模式，我在这里进一步描述:

This is a common pattern for many-to-many relations, which I further described here: Many to Many relationship in Firebase