Cloud Firestore和数据建模：从RDBMS到No-SQL
chr*_*ang 5 rdbms nosql firebase google-cloud-firestore
我正在构建一个使用Cloud Firestore（不是Firebase实时数据库）作为后端/数据库的iOS应用。
Google试图将新项目推向Cloud Firestore，老实说，拥有新项目的开发人员应选择使用Firestore（更好的查询，更容易的扩展等）。
我的问题与任何关系数据库开发人员在切换到无SQL数据库时一样：数据建模
我有一个非常简单的场景，我将首先解释如何使用MySQL配置它：
我想在表格视图中显示帖子列表，并且当用户单击一个帖子以展开并显示该帖子的更多详细信息时（假设是编写该帖子的用户）。听起来很简单。
在关系数据库世界中，我将创建2个表：一个名为“ posts ”的表和一个名为“ users ”的表。在“ posts ”表中，我将具有一个指示用户的外键。问题解决了。
可怜的巴里，从来没有时间写帖子:(
使用这种方法，我可以轻松实现我所描述的内容，而且，如果用户更新了他/她的详细信息，则只需在一个地方进行更改即可完成。
现在让我们切换到Firestore。我想将RDBMS的表名视为Firestore的集合，并将表的内容/结构视为文档。
在我看来，我有2种可能的解决方案：
解决方案1：
遵循与RDBMS相同的逻辑：在posts集合内，每个文档应具有一个名为“ userId”的键，其值应为该用户的documentId。然后通过获取帖子，您将认识用户。第二次查询数据库将获取所有与用户相关的详细信息。
解决方案2：
数据重复：每个帖子都应该有一个映射（嵌套对象），该映射具有名为“ user”的键，并包含所需的任何用户值。这样，用户数据将被附加到它写的每个帖子上。
从RDBMS的规范化领域来看，这听起来很可怕，但是许多no-SQL文档都鼓励重复（？）。
- 这是有效的方法吗？
- 当用户需要更新他/她的电子邮件地址时会发生什么？您如何轻松地确保在所有位置更新电子邮件？
我在第二种解决方案中看到的唯一好处是，您可以在一个调用中同时获取帖子和用户数据。
对于这种简单但非常常见的情况，还有其他解决方案吗？
ps：对我轻松一点，第一次使用no-sql dev。
提前致谢。
| 归档时间： |
|
| 查看次数： |
608 次 |
| 最近记录： |