我正在构建一个使用 Cloud Firestore(不是 Firebase 实时数据库)作为后端/数据库的 iOS 应用程序。
Google 正试图将新项目推向 Cloud Firestore，老实说，拥有新项目的开发人员应该选择加入 Firestore(更好的查询、更易于扩展等)。
我的问题与任何关系数据库开发人员在切换到非 SQL 数据库时遇到的问题相同:数据建模
我有一个非常简单的场景，我将首先解释如何使用 MySQL 配置它:
我想在表格 View 中显示帖子列表，当用户单击一个帖子以展开并显示该帖子的更多详细信息时(假设是撰写该帖子的用户)。听起来很容易。
在 关系数据库世界 ，我将创建 2 个表:一个名为“ 帖子 ”，一个名为“ 用户 ”。在“ 帖子”表中，我会有一个指示用户的外键。问题解决了。
可怜的巴里，从来没有时间写一篇文章:(
使用这种方法，我可以轻松实现我所描述的内容，而且，如果用户更新了他/她的详细信息，您只需在一个地方更改它就可以了。
现在让我们切换到 Firestore。我喜欢将 RDBMS 的表名视为 Firestore 的集合，将表的内容/结构视为文档。
在我看来，我有两种可能的解决方案:
解决方案1:
遵循与 RDBMS 相同的逻辑:在 内部帖子 集合，每个文档都应该有一个名为“userId”的键，值应该是该用户的 documentId。然后通过获取帖子，您将了解用户。查询数据库第二次 将获取所有与用户相关的详细信息。
解决方案2:
数据重复:每个帖子都应该有一个 map (嵌套对象)，其键名为“user”并包含您想要的任何用户值。通过这样做，用户数据将被附加到它写的每一篇文章。
来自 RDBMS 的规范化领域，这听起来很可怕，但许多非 SQL 文档鼓励重复(？)。
我在第二个解决方案中看到的唯一好处是您可以在一次调用中获取帖子和用户数据。
对于这种简单但非常常见的情况，还有其他解决方案吗？
ps:对我放轻松，第一次没有SQL开发。
提前致谢。
最佳答案
使用解决方案 1。关于嵌套与不嵌套的指导将取决于这些实体的 N 对 M 关系(例如，是 1 对多还是多对多？)。
如果您认为不访问实体的“父级”就永远不会访问该实体，则嵌套可能是合适的。在 Firestore(或基于文档的 noSQL 数据库)中，您应该根据嵌套实体的预期大小来决定是将该实体直接嵌套在文档中还是子集合中。例如，聊天中的消息应该是一个子集合，因为它们总共可能超过最大文档大小。
Mongo 是领先的 noSQL 数据库，提供了一些指南 here
Firestore 还提供了 docs
希望这可以帮助
关于firebase - Cloud Firestore 和数据建模 : From RDBMS to No-SQL，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51336759/