Firebase：如何构造公共/私有用户数据

当然，我数据库中的用户拥有可以公开访问的信息，以及只有他们才应该看到的其他信息。我正在考虑两种不同的方法来实现这一点

选项1:让

/users/$uid

仅由该用户可读，并且让

/users/$uid/profile

任何人都可读

---

选项2:使

/users/$uid

仅由该用户可读，并具有公开的

/profiles/$uid

。这遵循了更平坦的数据结构的建议，但我不认为它在这种情况下更好。

了解“更平坦”结构为什么更好的最简单方法是查看如何保护它以及如何实现功能

您的第一个结构是：

users: {
  uidOfJacob: {
    stackId: 884522,
    ssn: "999-99-9999",
    profile: {
      displayName: "Jacob Philips"
    }

  },
  uidOfPuf: {
    stackId: 209103,
    ssn: "999-99-9999",
    profile: {
      displayName: "Frank van Puffelen"
    }
  }
}

您可以使用以下方法来保护它：

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth.uid == $uid",
        ".write": "auth.uid == $uid"
        "profile": {
          ".read": true
        }
      }
    }
  }
}

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth.uid == $uid",
        ".write": "auth.uid == $uid"
      }
    },
    "profiles": {
      ".read": true,
      "$uid": {
        ".write": "auth.uid == $uid"
      }
    }
  }
}

拥有公共信息的主要原因之一是能够显示该信息的列表。在JavaScript中：

ref.child('users').child(???).child('profile').on('child_added'...

这不起作用，因为我们在

中放了什么？

。Firebase操作需要能够从一个位置读取整个列表，并且用户需要对整个位置具有读取权限（不仅仅是对单个子节点）

如果我们对数据进行结构化，将公共信息与私人信息分开，我们会得到：

users: {
  uidOfJacob: {
    stackId: 884522,
    ssn: "999-99-9999",
    profile: {
      displayName: "Jacob Philips"
    }

  },
  uidOfPuf: {
    stackId: 209103,
    ssn: "999-99-9999",
    profile: {
      displayName: "Frank van Puffelen"
    }
  }
},
"profile": {
  uidOfJacob: {
    displayName: "Jacob Philips"
  },
  uidOfPuf: {
    displayName: "Frank van Puffelen"
  }
}

您可以使用以下方法来保护它：

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth.uid == $uid",
        ".write": "auth.uid == $uid"
        "profile": {
          ".read": true
        }
      }
    }
  }
}

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth.uid == $uid",
        ".write": "auth.uid == $uid"
      }
    },
    "profiles": {
      ".read": true,
      "$uid": {
        ".write": "auth.uid == $uid"
      }
    }
  }
}

不获取公共用户配置文件列表，您可以执行以下操作：

ref.child('profiles').on('child_added'...

---

这将起作用，因为每个人都有

配置文件的阅读权限

我当前的用例是在用户id已知的情况下查看配置文件信息，这就是为什么我很难看到差异的原因。更嵌套的方法会阻止获取配置文件列表，这些配置文件可能会在以后派上用场。这基本上意味着新用户在注册后，需要在数据库中写入两次：1。“用户”节点的新条目（uid及其子节点），2。“配置文件”节点的新条目（具有displayName子节点的uid）@FrankVanPuffelen@Ewoks是的，没错。Frank的方法在NoSQL数据库设计中很常见，在这种方法中，读性能得到了提高，但写性能却降低了。