我正在创建一个原型组列表应用程序。我想要以下对象：
我认为我应该如下构建：
http://myapp.firebase.io/user/
http://myapp.firebase.io/user/uid/lists/
http://myapp.firebase.io/list/
http://myapp.firebase.io/item/listid/
http://myapp.firebase.io/comment/itemid
其中http://myapp.firebase.io/user/uid/lists/指向列出唯一ID，http://myapp.firebase.io/item/listid/指向给定列表的所有项目对象，http://myapp.firebase.io/comment/itemid指向给定项目的所有评论。< / p>
这种结构有意义吗？我之所以这样做而不是进一步嵌套（例如http://myapp.firebase.io/list/listid/item/表示项目而http://myapp.firebase.io/list/listid/item/itemid/comment表示注释）是因为它在文档中说每当你获取一个对象时就会获取所有子项。有时候（甚至大部分时间）我想要获取列表的项目，但不是每个项目的评论。我可能只想在用户点击该项目时这样做。
答案 0 :(得分：2)
在NoSQL数据库中，您应该为数据建模以确定如何使用它。我强烈建议您阅读此article on NoSQL data modeling。
顶层结构似乎没问题，并且没有违反Firebase's recommendation to limit nesting of data。但是还有很多其他地方你可能仍然会犯错（这也是Stack Overflow这个问题有点过于宽泛的原因之一，但无论如何我都会尝试回答一些问题）。
我将用户列表分成单独的顶级节点：
/userlists/$uid/$listid
这样/users/$uid个节点只包含用户的个人资料信息，您可以便宜地显示用户列表。您甚至可以考虑将用户配置文件中最明显的方面拆分为另一个顶级节点，以使这种列表的显示更便宜。
/usernames/$uid
在这种情况下，您将复制数据。但是存储（相对）便宜，而对更常见的数据读取进行优化是NoSQL数据库可以很好地扩展的原因之一。
您可能会注意到，我专注于显示用户名列表，检索用户列表以及访问特定用户的配置文件。这些是用例，我们将数据建模以适应它们。
在NoSQL数据库中，您应该为您的应用访问它的方式建模数据。我强烈建议您阅读此article on NoSQL data modeling。
之后，写出用例列表，看看如何最轻松地访问数据。自由地denormalize偶尔复制数据，以适应用例。使用multi-location updates使非规范化和重复数据与其主要实体保持同步。