Firebase：我的数据结构应该如此平坦？

我正在构建一款跟踪用户位置并更新Firebase的应用。我已阅读关于结构数据的文档，但仍有几个问题。Firebase：我的数据结构应该如此平坦？

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

users 
    $id 
    -position 
    -other attr

VS：

user_position 
    $id 

users 
    $id 
    -other attr.

在什么情况下会第一个设计作品最好的，第二个？

来源

2017-07-30 dmr07

@philipxy我不同意。任何一种设计都可以提供位置坐标。例如2：用户0的路径是*/rootref/27_6N-82_2W/uid_0 *，明天将是*/rootref/30_5N-77_7W/uid_0 *。然后，对uid_0的查询将在返回的键中显示它们的坐标。一般来说，没有真正的方法可以回答这个问题，因为Firebase的结构可以满足正在进行的查询类型和需要的数据。也许更多的信息更新这个问题将有助于我们理解用例。 – Jay

如果你正在考虑这个选择，*你跟随什么程序，你坚持*？如果您没有遵循设计指南（不要与编程/产品手册混淆，以告诉您如何表达与实现设计相关的内容），那么请查找信息建模和数据库设计的一些介绍，你被卡住了。 – philipxy

@Jay明白了，谢谢。 – philipxy

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

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

两种最常见的原因是：

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

来源

2017-07-30 22:24:18

Firebase：我的数据结构应该如此平坦？

回答

相关问题