📅  最后修改于: 2021-01-02 03:36:03             🧑  作者: Mango
在上一节中,我们了解了如何设置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":"JavaTpoint",
"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":"JavaTpoint",
"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":{...}
}
}