2016-07-29 42 views
7

当然,我的数据库中的用户具有可公开访问的信息以及他们应该看到的其他信息。我正在考虑两种不同的方式来实现这一点。Firebase:如何构建公共/私人用户数据

选项1:/users/$uid只能由该用户阅读并且/users/$uid/profile可以被任何人阅读。

选项2:保留/users/$uid只能由该用户读取,并且有公开的/profiles/$uid。这遵循一个更平坦的数据结构的建议,但我不明白在这种情况下它有多好。

回答

12

要理解为什么“扁平”结构更好,最简单的方法就是看你如何保护它以及如何实现功能。

你的第一个结构是:

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

+0

我当前的用例是在用户标识已知时查看配置文件信息,这就是为什么我很难看出差异。更多的嵌套方法可以防止获取配置文件列表,这些配置文件稍后可能会派上用场。 –

+0

这基本上意味着新用户在注册后需要在数据库中写入两次:1.用于“用户”节点的新条目(与其子节点一起使用的uid)2.用于“配置文件”节点的新条目(具有displayName子节点的uid) ? @FrankVanPuffelen – Ewoks

+2

@Ewoks是的,这是正确的。 Frank的方法在NoSQL数据库设计中很常见,其中读写性能的提高是以写性能下降为代价的。 –