Question

我刚刚学习Firebase，我想知道为什么需要自定义引用键而不是仅使用childByAutoId。文档中的示例大致类似于以下内容：

{
  "users": {
    "alovelace": {
      "name": "Ada Lovelace",
      "contacts": { "ghopper": true },
    },
    "ghopper": { ... },
    "eclarke": { ... }
  }
}

但为什么不使用像

这样的东西

{
  "users": {
    "gFlmT9skBHfxf7vCBCbhmxg6dll1": {
      "name": "Ada Lovelace",
      "contacts": { "ghopper": true },
    },
    "gFlmT9skBHfxf7vCBCbhmxg6dll2": { ... },
    "gFlmT9skBHfxf7vCBCbhmxg6dll3": { ... }
  }
}

虽然我更喜欢第一个例子用于可读性目的。除此之外，是否会对Firebase功能和其他与开发相关的内容（如查询，更新等）产生任何影响？谢谢！

Answer 1

Firebase的childByAutoId方法非常适合在集合中生成密钥：

需要按插入时间订购商品
物品没有自然键的地方
如果同一项目多次出现则不成问题

在一组用户中，这些条件（通常）都不适用：订单无关紧要，用户只能在集合中出现一次，而执行项具有自然键。

文档中的示例可能不清楚最后一个。存储在Firebase数据库中的用户通常来自不同的系统，通常来自Firebase身份验证。该系统为用户提供了唯一的ID，在Firebase身份验证的情况下称为 UID 。此UID是用户的唯一标识符。因此，如果您拥有一组用户，则使用其UID作为密钥可以轻松地根据用户ID查找用户。在文档示例中，只需读取密钥，就好像它们是该用户的UID（友好可读版本）一样。

在您的示例中，假设您已经阅读了Ada Lovelace的节点并想要查找她的联系人。您需要在/users上运行查询，这会在您添加用户时变得越来越昂贵。但是在文档的模型中，您确切地知道需要阅读的节点：/users/ghopper。

为什么在Firebase中提供自定义引用键而不是childByAutoId

1 个答案: