Firebase：我的数据结构应该有多平坦？答案

【问题标题】：Firebase: How flat should my data structure be?Firebase：我的数据结构应该有多平坦？
【发布时间】：2017-07-31 06:24:18
【问题描述】：

我正在构建一个用于跟踪用户位置并更新 Firebase 的应用。我已阅读有关结构数据的文档，但仍有一些问题。

我正在考虑以两种方式之一来构建数据，但无法确定是哪一种。

users
  $id 
    -position
    -other attr

对比：

user_position
  $id

users
  $id
    -other attr.

第一个设计在什么情况下效果最好，第二个？

【问题讨论】：

@philipxy 我不同意。任何一种设计都可以提供位置坐标。例如2：用户0的路径是/rootref/27_6N-82_2W/uid_0，明天是/rootref/30_5N-77_7W/uid_0。然后对 uid_0 的查询将在返回的键中显示它们的坐标。但总的来说，没有真正的方法来回答这个问题，因为 Firebase 的结构可以适应正在执行的查询类型和需要哪些数据。也许用更多信息更新问题将有助于我们理解用例。
如果您正在考虑这个选择，您正在遵循什么程序，而您却被困住了？如果您没有遵循设计指南（不要与告诉您如何表达与实现设计相关的内容的编程/产品手册混淆），那么请查找信息建模和数据库设计的一些介绍并遵循直到你被卡住了。
@Jay 知道了，谢谢。
@philipxy 我想我主要在努力解决的是观察两个节点（嵌套），每个查询具有较小的数据树（即第二个选项）还是观察一个节点，使用稍大的数据树。
观察者的重量很轻，因此在任何一种情况下“应变”都可以忽略不计。但是 - 子数据的数量会影响这一点，但我们不知道您在谈论多少子数据，所以真的没有办法回答。

【解决方案1】：

如果您只为每个用户保留一个位置（因为您使用单数 user_position 似乎就是这种情况），那么这两种结构之间没有有用的区别。在这种情况下，用户的位置只是另一个属性，恰好有两个值（纬度和经度）。

但如果您想为每个用户保留多个职位，那么您的第一个结构是混合实体类型：users 和 user_positions。对于 Firebase 数据库，这是一种反模式。

两个最常见的原因是：

假设您要显示用户名列表（或任何特定的单值属性）。对于第一个结构，您还需要读取所有用户的所有职位列表，以获取名称列表。使用第二种结构，您只需读取用户的属性。如果这仍然比您需要的数据多得多，请考虑保留/user_names 列表以获得最佳读取性能。
许多开发人员最终希望针对用户位置和其他用户属性使用不同的访问规则。在第一个结构中，只有通过将读取权限从顶部 /users 向下推到树中的较低位置才能实现。在第二种结构中，您可以只为/users 和/user_positions 授予单独的权限。

【讨论】：