该做什么和不该做什么

错误的方法

考虑以下结构

{
  "users": {

    // Uniquely generated IDs for children is common practice,
    // it's actually really useful for automating child creation.
    // Auto-incrementing an integer for a key can be problematic when a child is removed.

    "-KH3Cx0KFvSQELIYZezv": {     
      "name": "Jon Snow",
      "aboutMe": "I know nothing...",
      "posts": {
        "post1": { 
          "body": "Different roads sometimes leads to the same castle", 
          "isHidden": false
        },
        "post2": { ... },
        // Possibly more posts
      }
    },
    "-KH3Dx2KFdSLErIYZcgk": { ... },     // Another user
    // A lot more users here
  }
}

这是不该做的一个很好的例子。如上所述的多嵌套结构可能非常有问题，并且可能导致巨大的性能挫折。

Firebase 访问节点的方式是下载所有子节点的数据，然后迭代所有相同级别的节点（所有父节点的子节点）。现在，想象一个包含多个用户的数据库，每个用户都有数百（甚至数千） 个帖子。在这种情况下访问帖子可能会加载数百兆字节的未使用数据。在更复杂的应用程序中，嵌套可能比仅仅 4 层更深，这将导致更多无用的下载和迭代。

正确的方式

扁平化相同的结构看起来像这样

{
  // "users" should not contain any of the posts' data
  "users": {
    "-KH3Cx0KFvSQELIYZezv": {
      "name": "Jon Snow",
      "aboutMe": "I know nothing..."
    },
    "-KH3Dx2KFdSLErIYZcgk": { ... },
    // More users
  },

  // Posts can be accessed provided a user key
  "posts": {
    "-KH3Cx0KFvSQELIYZezv": {     // Jon Snow's posts
      "post1": { 
        "body": "Different roads sometimes leads to the same castle", 
        "isHidden": false
      },
      "post2": { ... },
      // Possibly more posts
    },
    "-KH3Dx2KFdSLErIYZcgk": { ... },
    // other users' posts
  }
}

通过迭代较少的节点来访问目标对象，这可以节省大量开销。所有的用户没有任何帖子不会在存在职位分支，并在这些用户，以便迭代方式不对以上是完全无用的。