database-design - 将 Firebase 用户 UID 用于相关数据库条目的键 - 好的还是坏的做法？

Question

使用用户的 UID(由 Firebase 在通过 Firebase 身份验证创建用户时生成)作为关联数据库条目的键有什么问题吗？

例如，这里:

/config/user.uid/configObject

...每个用户都有一个配置条目。由于 Firebase 的数据库规则(父节点上的设置适用于所有子节点)，通常需要创建一个单独的配置树(按照示例， /users 树需要被读写保护)。

我认为这可能是不好的做法的唯一原因是，如果用户的 UID 发生变化...... Firebase 是否保证这永远不会发生？我缺少什么吗？

Answer 1

特定用户的 UID 永远不会改变(尽管他们做了 change the format a few months ago ；旧格式包括提供者)。

这是一个很好的做法，在许多情况下是必要的，并且可能在某处推荐。正如您所提到的，您需要将用户信息非规范化为多个节点以获得更好的性能和授权。它在伪代码/规则中可能看起来像这样:

- users_private (.read: $uid == auth.uid)
  - $uid
    - email

- users_public (.read: true)
  - $uid
    - name
    - photo

- users_roles (.read: dependent on some other rules)
  - $uid
    - is_admin
    - is_editor