我正在构建一个使用Cloud Firestore（不是Firebase实时数据库）作为后端/数据库的iOS应用程序 .
Google正在尝试将新项目推向Cloud Firestore，说实话，开发新项目的开发人员应该选择加入Firestore（更好的查询，更容易扩展等等） .
我的问题与任何关系数据库开发人员在切换到无SQL数据库时的问题相同： data modeling
我有一个非常简单的场景，我将首先解释如何使用MySQL配置它：
我希望在表格视图中显示帖子列表，以及当用户点击一个帖子进行展开并显示该帖子的更多详细信息时（比如编写该帖子的用户） . 听起来很容易 .
在一个 relational database world 中，我会创建两个表：一个名为“ posts " and one named " users ". Inside the " posts ”的表我会有一个指示用户的外键 . 问题解决了 .
可怜的巴里，从来没有时间写一篇文章:(
使用这种方法，我可以轻松实现我所描述的内容，而且，如果用户更新他/她的详细信息，您只需在一个地方更改它就可以完成 .
现在让我们切换到Firestore . 我喜欢将RDBMS的表名称视为Firestore的集合，将表的内容/结构视为文档 .
在我看来，我有两种可能的解决方案：
Solution 1:
遵循与RDBMS相同的逻辑：在 posts 集合中，每个文档都应该有一个名为"userId"的键，值应该是该用户的documentId . 然后通过获取帖子，您将了解用户 . 查询数据库 a second time 将获取所有与用户相关的详细信息 .
Solution 2:
数据复制：每个帖子都应该有一个映射（嵌套对象），其中包含一个名为“user”的键，并包含您想要的任何用户值 . 通过这样做，用户数据将附加到它写入的每个帖子 .
来自RDBMS的规范化领域这听起来很可怕，但是很多非SQL文档都鼓励重复（？） .
-
这是一种有效的方法吗？
-
当用户需要更新他/她的电子邮件地址时会发生什么？您是否轻松确保电子邮件在所有地方都得到更新？
我在第二个解决方案中看到的唯一好处是您可以在一次调用中获取发布和用户数据 .
对于这个简单但非常常见的情况，还有其他解决方案吗？
ps：对我很轻松，第一次没有-sql dev .
提前致谢 .
1 回答
使用解决方案1.关于嵌套与非嵌套的指导将取决于这些实体的N对M关系（例如，它是1对多，多对多？） .
如果您认为在不访问其“父”的情况下永远不会访问实体，则嵌套可能是合适的 . 在firestore（或基于文档的noSQL数据库）中，您应该根据嵌套实体的期望大小决定是将该实体直接嵌套在文档中还是嵌入子集合中 . 例如，聊天中的消息应该是子集合，因为它们总共可能超过最大文档大小 .
Mongo，一个领先的noSQL数据库，提供了一些指南here Firestore也提供了docs希望这有助于