本頁面由 Cloud Translation API 翻譯而成。

建立資料庫結構

本指南涵蓋資料架構的幾個重要概念，並在 Firebase Realtime Database 中建構 JSON 資料的做法。

要建立結構良好的資料庫，機構必須審慎顧慮。最重要的是，您必須規劃資料儲存方式。以簡化這項程序

資料的結構：這是 JSON 樹狀結構

所有 Firebase Realtime Database 資料都會儲存為 JSON 物件。您可以將資料庫想像成雲端託管 JSON 樹狀結構。與 SQL 資料庫不同的是，這個資料庫中沒有表格或記錄。將資料新增至 JSON 樹狀結構時，資料會在現有 JSON 結構中變成一個節點，且包含關聯的金鑰。您可以提供自己的金鑰例如使用者 ID 或語意名稱 push()。

如果您要建立自己的金鑰，金鑰必須採用 UTF-8 編碼，為 768 個位元組，且不得包含 .、$、#、[、]、/ 或 ASCII 控制項字元數：0-31 或 127。您不能在值中使用 ASCII 控製字元

例如，假設即時通訊應用程式可讓使用者儲存建立設定檔和聯絡人清單一般使用者設定檔位於路徑，例如 /users/$uid。使用者 alovelace 的資料庫項目可能如下所示：

{
  "users": {
    "alovelace": {
      "name": "Ada Lovelace",
      "contacts": { "ghopper": true },
    },
    "ghopper": { ... },
    "eclarke": { ... }
  }
}

雖然資料庫使用 JSON 樹狀結構，但儲存在資料庫中的資料會以特定原生類型表示，對應可用的 JSON 類型協助您編寫更易於維護的程式碼

資料結構的最佳做法

避免建立巢狀資料

由於 Firebase Realtime Database 允許建立最多 32 層的巢狀資料巢狀結構，您可能會想以此為預設結構。不過，從資料庫內的某個位置擷取資料時，您也會擷取所有子節點此外，如果您授予他人讀取或寫入權限也會授予資料庫內所有資料的存取權節點。因此，在實務上，最好將資料結構保持扁平

以下舉例說明巢狀資料品質不佳的原因，多重巢狀結構：

{
  // This is a poorly nested data architecture, because iterating the children
  // of the "chats" node to get a list of conversation titles requires
  // potentially downloading hundreds of megabytes of messages
  "chats": {
    "one": {
      "title": "Historical Tech Pioneers",
      "messages": {
        "m1": { "sender": "ghopper", "message": "Relay malfunction found. Cause: moth." },
        "m2": { ... },
        // a very long list of messages
      }
    },
    "two": { ... }
  }
}

使用這種巢狀設計，疊代資料就會造成問題。適用對象例如，列出即時通訊對話的標題需要整個 chats 內容，包括所有成員與訊息。

壓平合併資料結構

如果資料是分割成獨立路徑也稱為去正規化如此就能有效率地下載，視需要在個別呼叫中下載。您可以考慮使用這個簡化結構

{
  // Chats contains only meta info about each conversation
  // stored under the chats's unique ID
  "chats": {
    "one": {
      "title": "Historical Tech Pioneers",
      "lastMessage": "ghopper: Relay malfunction found. Cause: moth.",
      "timestamp": 1459361875666
    },
    "two": { ... },
    "three": { ... }
  },

  // Conversation members are easily accessible
  // and stored by chat conversation ID
  "members": {
    // we'll talk about indices like this below
    "one": {
      "ghopper": true,
      "alovelace": true,
      "eclarke": true
    },
    "two": { ... },
    "three": { ... }
  },

  // Messages are separate from data we may want to iterate quickly
  // but still easily paginated and queried, and organized by chat
  // conversation ID
  "messages": {
    "one": {
      "m1": {
        "name": "eclarke",
        "message": "The relay seems to be malfunctioning.",
        "timestamp": 1459361875337
      },
      "m2": { ... },
      "m3": { ... }
    },
    "two": { ... },
    "three": { ... }
  }
}

現在只要下載每個對話的位元組數，可以快速擷取或顯示中繼資料透過使用者介面建立聊天室使用者可以分別擷取訊息，並在收到郵件時顯示。讓 UI 保持回應和快速

建立可大規模調整的資料

建構應用程式時，建議您下載部分清單。這種情況尤其常見，因為這份清單含有數千筆記錄。如果是靜態的單向關係，子項物件

有時候這種關係比較多變，或者您可能得並將這項資料去標準化。通常您可以使用查詢將資料去標準化擷取部分資料，如擷取資料。

但這可能不夠。以雙向關係為例方便使用者和群組使用者可以加入某個群組，而群組則是由使用者清單當您決定要讓使用者加入哪些群組時情況變得越來越複雜

需要能以流暢的方式列出使用者所屬的群組只擷取這些群組的資料。群組索引有助於最棒的是：

// An index to track Ada's memberships
{
  "users": {
    "alovelace": {
      "name": "Ada Lovelace",
      // Index Ada's groups in her profile
      "groups": {
         // the value here doesn't matter, just that the key exists
         "techpioneers": true,
         "womentechmakers": true
      }
    },
    ...
  },
  "groups": {
    "techpioneers": {
      "name": "Historical Tech Pioneers",
      "members": {
        "alovelace": true,
        "ghopper": true,
        "eclarke": true
      }
    },
    ...
  }
}

您可能會注意到，這麼做會儲存分別位於 Ada 的記錄下方目前 alovelace 已在和 techpioneers 已列在 Ada 的個人資料中。所以要刪除 Ada 就必須在兩個位置更新

這是雙向關係必要的備援功能。您可以快速有效地擷取 Ada 成員，即使這些使用者或組織調整至數百萬個或 Realtime Database 個安全性規則防止存取部分記錄。

這個方法會把 ID 列為鍵，並設定值變成 true，所以檢查索引鍵就像讀取一樣簡單請/users/$uid/groups/$group_id，並確認電子郵件地址是否為 null。建立索引的速度較快比起查詢或掃描資料更有效率