Question

我正在编写一个使用Firebase实时数据库的Android应用。这是我第一次使用任何Firebase产品，因此到目前为止它已经是一个相当大的学习曲线，随着应用程序的开发已经有了多个数据结构变化，我学到了更多的最佳实践。

我理解我应尽可能avoid nesting data，所以此刻我的数据就这样被摧毁了;

{
  "projects" : {
    "jyZdNutWvUbA4XrQ3Gbb17rByyA2" : {
      "-KcAq7Cx7wQL99_3Jo9l" : {
        "area" : "R",
        "dateCreated" : 1486257427801,
        "dateModified" : 1486257427801,
        "latitude" : 999.9,
        "location" : "R",
        "longitude" : 999.9,
        "weather" : "R"
      },
      "-KcAqACaNOHSELyNfSu4" : {
        "area" : "A",
        "dateCreated" : 1486257440065,
        "dateModified" : 1486257440065,
        "latitude" : 999.9,
        "location" : "A",
        "longitude" : 999.9,
        "weather" : "A"
      }
    }
  }
}

我有一个projects节点，它将存储所有项目数据，然后是存储每个用户项目的唯一userid子节点（上面代码段中只有一个用户），然后是唯一{ {1}}（上例中有2个项目），最后是特定项目的所有细节。作为应用程序的想法只需要适用于可以接受的projectid并从那里拉出所有孩子。

此后我决定添加与其他用户共享项目的功能。我发现this post（下面的示例代码，如果我在我的场景中实现的话）似乎可以做我想要的，但我担心它效率会降低，因为我现在需要扫描所有项目并挖掘一个额外的项目孩子深（假设我使用下面详述的确切模式），然后才能检查特定用户是否是所有者或允许读/写的规则？

userid

此外，我遇到的许多示例数据结构倾向于以与第二个代码片段类似的方式存储数据，即

{ "projects" : { "-KcAq7Cx7wQL99_3Jo9l" : { "area" : "R", "dateCreated" : 1486257427801, "dateModified" : 1486257427801, "latitude" : 999.9, "location" : "R", "longitude" : 999.9, "weather" : "R", "owner" : ""jyZdNutWvUbA4XrQ3Gbb17rByyA2", "shares" : { "uid" : "true" } }, "-KcAqACaNOHSELyNfSu4" : { "area" : "A", "dateCreated" : 1486257440065, "dateModified" : 1486257440065, "latitude" : 999.9, "location" : "A", "longitude" : 999.9, "weather" : "A" "owner" : ""jyZdNutWvUbA4XrQ3Gbb17rByyA2", "shares" : { "uid" : "true" } } } }而目前我projects/projectid/userid对我来说看起来效率更高，因为你不需要深入研究每个项目来检查你是否有读/写权限。我是否误解了它如何与我的方法一起工作的概念？

对于数据库而言，应用程序存在巨大的疑问，所以无论我的结构如何，我认为性能不会受到太大影响，但我确实希望尽可能坚持最佳实践。

共享数据的Firebase数据结构

0 个答案: