我目前正在发现Firebase,并尝试对其进行评估以进行更多项目。目前,我正在使用一个非常简单的“Todo list”应用程序进行测试,其中列表可以与朋友分享。
我已经阅读了有关扁平化数据结构以避免复杂性的文档,我想出了以下结构:
iA
现在我想知道如何在不获取其他用户的所有列表的情况下加载我的所有“列表”。
非常感谢您的帮助和建议。
祝你好运
答案 0 :(得分:3)
如果您要向用户显示她有权访问的所有TODO列表,我会将该列表存储在Firebase中。
从Mathew的样本数据中窃取:
{
users: {
user1Id: {
//other data
lists: {
list1Id: true,
list5Id: true
}
}
},
lists: {
list1Id: {
//other data,
memberships: {
user1Id: true
}
}
}
}
因此,在上面的代码段中,仅必须加载/users/user1Id
才能知道他有权访问哪些列表。您不需要执行任何查询来确定这一点,因此请加载用户列表中的"列表"很便宜。您甚至可以在用户的数据中存储要为每个列表显示的信息,从而无需查找。
{
users: {
user1Id: {
//other data
lists: {
list1Id: "Groceries for BBQ",
list5Id: "4th of July parties to go to"
}
}
},
lists: {
list1Id: {
title: "Groceries for BBQ",
//other data,
memberships: {
user1Id: true
}
}
}
}
请注意,在这两种情况下,我们都在复制数据。我建议在许多情况下这样做,因为它加快了读取特定用例的数据。但当然,当您第一次添加数据时,必须将数据写入多个位置。而且,您还需要考虑是否/如何更新该数据的所有实例,例如列表标题更改。
阅读这篇文章,以获得有关该主题的精彩介绍:https://medium.com/@collardeau/es6-promises-with-firebase-76606f36c80c或我对该文章的输入的答案:How to write denormalized data in Firebase
我只是意识到你应该稍微规范化这些数据。 Firebase建议您在不需要时不要构建巢穴。在这种情况下,您可能希望查看用户的个人资料数据,并且您不需要她的列表。或者用户只想查看她的列表,而不是她的个人资料数据。因此,更加规范化的模型将是:
{
users: {
user1Id: {
//profile data
}
},
users_lists: {
user1Id: {
list1Id: "Groceries for BBQ",
list5Id: "4th of July parties to go to"
}
lists: {
list1Id: {
title: "Groceries for BBQ",
//other data,
memberships: {
user1Id: true
}
}
}
}
它与以前的数据完全相同,但现在users_lists
位于单独的顶级数据结构中。
当然这种结构是否更好取决于您想要满足的用例。如果您始终在一个屏幕中显示用户的个人资料数据和待办事项列表,前者的效率会略高一些。但是,无论哪种数据结构都比大多数开发人员首先考虑的select * from all_todo_lists where user_id = me
更有效。 : - )
答案 1 :(得分:1)
没有数组,您的数据应该更像这样:
{
users: {
user1Id: {
//other data
}
},
lists: {
list1Id: {
//other data,
memberships: {
user1Id: true
}
}
}
}