假设我有一个典型的用户和组数据模型，其中用户可以属于多个组，并且一个组可以拥有多个用户。在我看来，Firebase 文档 https://www.firebase.com/docs/web/guide/structuring-data.html建议我通过复制组内的用户 ID 和用户内的组 ID 来建模数据，如下所示：
{
"usergroups": {
"bob": {
"groups": {
"one": true,
"two": true
}
},
"fred": {
"groups": {
"one": true
}
}
},
"groupusers": {
"one": {
"users": {
"bob": true,
"fred": true
}
},
"two": {
"users": {
"bob": true
}
}
}
}
为了维护这种结构，每当我的应用程序更新关系的一侧（例如，将用户添加到组）时，它也需要更新关系的另一侧（例如，将组添加到用户）。
我担心最终某人的计算机会在更新过程中崩溃，或者出现其他问题，并且关系的双方将失去同步。理想情况下，我想将更新放入事务中，以便双方都得到更新或双方都不更新，但据我所知，我无法使用 firebase 中当前的事务支持来做到这一点。
另一种方法是使用即将推出的 Firebase 触发器来更新关系的另一端，但触发器尚不可用，这似乎是一个相当重量级的解决方案，可以将消息发布到外部服务器，只是让该服务器保留冗余数据迄今为止。
因此，我正在考虑另一种方法，其中将多对多用户组成员资格存储为单独的端点：
{
"memberships": {
"id1": {
"user": "bob",
"group": "one"
},
"id2": {
"user": "bob",
"group": "two"
},
"id3": {
"user": "fred",
"group": "one"
}
}
}
我可以在“user”和“group”上添加索引，并发出 firebase 查询“.orderByChild(“user”).equalTo(...)”和“.orderByChild(“group”).equalTo(...)”分别确定特定用户的组和特定组的用户。
这种方法有什么缺点？我们不再需要维护冗余数据，那么为什么这不是推荐的方法呢？它是否比推荐的复制数据方法慢得多？
