Firebase实时数据库中的数据组织 _Firebase数据组织

本文概述

数据库结构
避免嵌套数据
展平数据结构

【Firebase实时数据库中的数据组织】在上一节中, 我们了解了如何设置Firebase控制台和Android应用程序以使用实时数据库。在本节中, 我们将讨论如何在Firebase或Firebase实时数据库中组织数据。我们已经知道Firebase中的数据是以JSON文件格式存储的。那么, Firebase实时数据库中JSON格式的含义是什么？

文章图片
数据库结构创建结构良好的数据库需要大量的前瞻性工作。这意味着我们需要计划如何保存数据并在以后检索数据, 以使该过程尽可能地容易。
在Firebase实时数据库中, 数据存储为JSON对象。我们可以将数据库视为云托管的JSON树。没有表和记录, 这意味着它是一个NoSQL数据库。可以将存储的数据表示为数据库中与可用JSON类型相对应的某些本机类型, 以帮助我们编写更具可维护性的代码。当我们将数据添加到JSON树时, 它成为现有JSON结构中具有关联键的节点。我们可以提供自己的密钥, 例如用户ID或名称, 也可以使用push()函数将其提供给我们。
让我们看一个示例, 以了解数据在JSON树的Firebase实时数据库中的外观。让我们考虑为聊天应用程序存储数据的示例。该聊天应用程序允许用户存储基本个人资料和联系人列表。用户配置文件将位于“用户/ $ uid”之类的路径上。用户是其中的一个节点, 并且将具有与ID关联的一种主键。因此, 我们可以唯一地访问每个。

{"Users": {"Student":{"name":"Shubham Rastogi", "contacts":{"Faculty":true}, }, "Faculty":{?}, "Staff":{?}}}

用户下的所有内容都是用户的特定节点, 我们将使用诸如Users.Students, Users.Mstudent和Users.Tsudent之类的引用来访问它们。这是基本的树结构, 其外观和我们注意到的是它有很多嵌套。在Cloud中, Firestore没有太多的嵌套, 并且嵌套会导致一些性能问题。
因此, 在上面的示例中, “学生”是“用户”下的一个节点。名称和联系人是“学生和教师”下的节点, “职员”是“用户”下的节点。
避免嵌套数据嵌套会导致某些性能下降。因此, 我们必须尽可能避免嵌套数据。这是必要的, 但我们避免使用它, 尤其是在我们拥有大型数据集的情况下, 因为这可能会降低性能。我们必须尝试使我们的数据结构尽可能平坦。
例：

{"Chats":{"One":{"title":"srcmini", "message":{"m1":{"sender":"Shubham", "message":"Send your weakly report"}"m2":{?}//A very long list of messages}}, "Two":{?}}}

这是一个嵌套不良的数据结构, 因为迭代Chats节点的子节点的子子节点需要获取对话标题列表。因此, 这可能需要数百兆的消息。在此示例中, 如果我们要遍历数据, 那么它将非常成问题。
展平数据结构为了避免嵌套数据, 请尝试在我们的数据结构中展平。将数据拆分到单独的路径将是更好的方法。因此, 它可以根据需要有效地下载单独的呼叫。

{//Chats contain only meta info about each conversation"chats":{"one":{"title":"srcmini", "lastMessage":"Student:whatever", "timestamp":1459754193228}, "Two":{...}, "Three":{...}}, //Messages are seperate from data we may want to iterate quickly but still easily// numbered the messages and queried, and organized by chat conversation ID"messages":{"one":{"m1":{"name":"Faculty", "message":"Send your Report", "timestamp":1459754195874}, "m2":{...}, "m3":{...}}, "Two":{...}, "Three":{...}}}