在firebase中,使用单独的端点建模许多关系是一个好主意吗？

假设我有一个典型的用户和组数据模型,其中用户可以在多个组中,一个组可以有许多用户.在我看来,firebase文档建议我通过在组内部复制用户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(...)"分别确定特定用户的组和特定组的用户.

这种方法的缺点是什么？我们不再需要维护冗余数据,为什么这不是推荐的方法？它是否明显慢于推荐的复制数据方法？

在您提出的设计中,您总是需要访问三个位置来向用户和她的群组展示:

的users孩子来确定用户的属性

在memberships确定她就是团体中的一员

在groups孩子确定组的属性

在文档的非规范化示例中,您的代码只需访问#1和#3,因为成员资格信息嵌入到users和groups.

如果再进一步规范化,则最终会为每个用户存储所有相关的组信息以及每个组的所有相关用户信息.使用这样的数据结构,您只需要读取一个位置即可显示组或用户的所有信息.

冗余在NoSQL数据库中不一定是坏事,实际上正是因为它加快了速度.

目前,我会选择一个辅助流程来定期扫描数据并协调它找到的任何不规则数据.当然,这也意味着常规客户端代码需要足够健壮以处理这种不规则数据(例如,指向用户的组,其中该用户的记录不指向该组).

或者,您可以设置一些高级.validate规则,以确保双方始终保持同步.我总是发现需要更多时间来实现,所以从不打扰.

您可能还想阅读此答案:Firebase数据结构和网址