該做什麼和不該做什麼

錯誤的方法

考慮以下結構

{
  "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
  }
}

通過迭代較少的節點來訪問目標物件，這可以節省大量開銷。所有的使用者沒有任何帖子不會在存在職位分支，並在這些使用者，以便迭代方式不對以上是完全無用的。