要理解为什么“扁平”结构更好,最简单的方法就是看你如何保护它以及如何实现功能。
你的第一个结构是:
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
}
}
}
}
}
其中一个主要的原因有公共信息是能够显示的信息列表。在JavaScript中:
ref.child('users').child(???).child('profile').on('child_added'...
这是行不通的,因为我们在???
中放了什么。 Firebase操作需要能够从一个位置读取整个列表,并且用户需要具有该整个位置的读取权限(而不仅限于各个子节点)。
如果我们结构中的数据对公众信息来自私人信息分开,我们得到:
{
"rules": {
"users": {
"$uid": {
".read": "auth.uid == $uid",
".write": "auth.uid == $uid"
}
},
"profiles": {
".read": true,
"$uid": {
".write": "auth.uid == $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"
}
}
},
"profile": {
uidOfJacob: {
displayName: "Jacob Philips"
},
uidOfPuf: {
displayName: "Frank van Puffelen"
}
}
你会先固定好公共用户配置文件,你会这样做:
ref.child('profiles').on('child_added'...
这将工作,因为每个人都有读权限o n profiles
。
我当前的用例是在用户标识已知时查看配置文件信息,这就是为什么我很难看出差异。更多的嵌套方法可以防止获取配置文件列表,这些配置文件稍后可能会派上用场。 –
这基本上意味着新用户在注册后需要在数据库中写入两次:1.用于“用户”节点的新条目(与其子节点一起使用的uid)2.用于“配置文件”节点的新条目(具有displayName子节点的uid) ? @FrankVanPuffelen – Ewoks
@Ewoks是的,这是正确的。 Frank的方法在NoSQL数据库设计中很常见,其中读写性能的提高是以写性能下降为代价的。 –