组织您的数据库

本指南介绍了关于数据架构的几个主要概念，以及在您的 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": { ... }
  }
}

现在，只需针对每个对话下载几个字节并快速提取元数据（以便在界面中列出或显示聊天室），即可遍历聊天室列表。消息可单独提取并在到达时显示，从而确保界面及时快速地响应。

创建可扩容的数据

构建应用时，最好下载列表的子集。 当列表含有成千上万条记录时，这种做法尤其常见。 当这种关系属于静态和单向关系时，您只需在父对象下嵌套子对象即可。

有时，这种关系更具动态性，或者需要对此数据进行反规范化。通常，您可以通过查询来检索该数据的子集，以便对该数据进行反规范化，如对数据进行排序和过滤中所述。

但即使这样也可能无法解决问题。以用户与群组之间的双向关系为例。用户可属于某个群组，群组可包含一系列用户。当需要确定用户属于哪些群组时，情况就会比较复杂。

我们需要的是一种巧妙的方法，不仅要列出用户所属的群组，而且只提取这些群组的数据。群组索引可在此发挥巨大作用：

// 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 一样简单。与查询或扫描数据相比，索引的速度更快、效率更高。

后续步骤