0

我正在阅读 MongoDB，但仍然无法理解在什么情况下我应该更喜欢面向文档的数据库而不是 Postgres 等传统数据库。

考虑以下情况：我有一个博客，其中包含帖子，用户可以对帖子发表评论。所以我创建了两个集合：users和posts. 每个都post包含一个嵌入式文档数组 - comments，因此每次我post从数据库加载一个，我都会自动获取所有comments. 这很好，事实上，如果我确定关系不会改变，Mongo 似乎是一个更好的选择。但一切都会。

1. 断绝关系。

假设我将决定在他/她的个人资料页面上显示用户的评论。我将不得不在by上创建一个索引posts.comments.user_id并从中选择。所以这与我在 RDBMS 中所做的基本相同。或者我将不得不复制所有内容并手动确保这两组在将来保持同步（在 Mongo 中没有触发器和没有事务）。postsuser._idcommentspostsusers

2.添加字段

现在我在帖子中添加了一个新字段，比如rating我想要设置的那些已经存在的记录rating = number of comments。但是我不能进行这种大规模更新。要么我为所有更新的文档( ) 设置相同的值，{ $set: {rating: 1} }要么我必须手动逐个循环。

3. 制作报告

如何找到最活跃的用户？因为没有joins- 首先，我必须提取顶部posts.comments.user_id并将它们保存在某个地方。然后一次_id一个并选择user.name。这可以通过保持user.namein来解决comment。但是，如果以后我需要更多字段怎么办？

我的问题是什么？

我有什么问题吗？这三种情况似乎是对博客应用程序的简单扩展。如果我从一开始就不是 100% 确定关系和统计的结构，并且......（在 99% 的真实案例中）我不应该使用 Mongo？

4

2 回答 2

2

非常有趣和有启发性的问题。

  1. 需求的变化意味着软件的变化。将评论从帖子转移给用户肯定是一个相当大的变化，但我仍然认为，使用 MongoDB 进行这样的更改可能比使用 RDBMS 更痛苦。例如，可以修改应用程序，使其可以同时处理两种变体：帖子中的评论和用户中的评论。这样，数据可以随着时间的推移而不是一次全部迁移到新结构。-- 在用户和帖子中保留评论对我来说似乎是一个相当糟糕的决定。如果数据经常变化，那是不去规范化它的有力论据。

  2. 您描述的更新在任何编程语言或 MongoDB 的本机 javascript shell 中实现都是微不足道的。查询语言本身不允许这种复杂的更新这一事实并不意味着它不能用 MongoDB 轻松完成。我认为查询语言比成熟的 SQL 更流线型实际上是一件好事。

  3. 仔细的非规范化（通过将 user.name 放入评论本身）确实可以在这里有所帮助。由于 user.name 很少会更改，因此对于这种非规范化来说，这比将评论同时放入用户和帖子中要好得多。再一次，如果您有选择地、动态地执行此操作，MongoDB 的灵活性就会开始大放异彩——您可以在访问时将 user.name 放入注释中，但可以编写应用程序以便处理这两种情况：如果用户.name 不在它被查找的评论中（然后可能写入评论以保存将来的查找）​​。您可以随时在评论中“缓存”更多属性。

一般来说，MongoDB 带来了一种更灵活、更敏捷的方式来思考数据结构并在数据库中实现它们。许多程序员发现它比 SQL 的僵化更直观、更容易使用。但是没有一种技术只有优势，你总能找到一种方法比另一种方法带来更好、更优雅的解决方案的问题。

于 2013-10-19T14:27:53.087 回答
0

您只需通过您的编程语言解决您的问题。修改 SQL 查询以改变结果是本能，但您只需使用 javascript 来提取新数据。

于 2013-10-19T16:33:34.747 回答