我什么时候应该使用 mongoDB 而不是关系数据库答案

【问题标题】：When should i use mongoDB instead of a relationnal database我什么时候应该使用 mongoDB 而不是关系数据库
【发布时间】：2019-05-09 22:30:42
【问题描述】：

我已经在 udemy 上学习了几门关于 NodeJS/Express、ReactJS/Redux 的课程，其中一些课程是 MERN STACK，我真的很喜欢它们。但讲师唯一没有真正解释的是选择MongoDB。在参加这些课程之前，我总是将PostgreSQL 或MariaBD 用于我所有的项目持久层。现在我刚刚在所有这些课程中使用MongoBD，但不知道在哪种情况下它是最好的选择与否。所有讲师都只是说，由于数据像 json json 数组一样存储，因此很容易解析，因为它与 Javascript 就像任何 JSON format 一样自然兼容。我真的很想了解使用 Mongo 的技术原因relationnal database 或不根据任何给定的项目要求，而不是仅仅使用它，因为讲师这样做

【问题讨论】：

这个问题的答案在这个视频youtube.com/watch?v=KWOSGVtHWqA
Mongodb 只是一个文档库 nosql 数据库

标签： mysql node.js mongodb express mern

【解决方案1】：

根据我的个人经验，当项目有点像社交媒体必须维护帖子、评论、喜欢、阻止、取消阻止时，我会使用 SQL。我希望你能明白。

Mongo Db 也可以用于上述项目类型，但它的聚合变得痛苦且不可读。

Mongo Db 适用于除社交媒体之外的所有项目。这又是我的经验。

【讨论】：

不太确定我明白你为什么说像“社交媒体”这样的项目不合适？对于发布文档，它非常适合文档模型...{ text: "post test", comments: [ { by: "bob", "MongoDB is awesome!"}], likedBy:[ "bob" ] }
好的，我举个例子。帖子将有 cmets 并且可以喜欢这些 cmets 等。现在，如果某个用户 B 正在评论帖子 P1。作为用户 A，当我看到帖子时，我会看到用户 B 评论，这是幸福的情况。现在，如果有阻止和取消阻止功能，那么作为用户 A，如果 A 阻止了 B 和许多其他情况，我不应该看到用户 B 的评论
从数据库中取出后，您能否仅将业务逻辑应用到 post 文档中的 cmets 的阻塞方式？
好的，所以 cmets 可以被任何用户屏蔽，因此每条评论还需要存储所有屏蔽 cmets 的用户及其被屏蔽时间。是的，这可以在 MongoDb 上完成，但我说它的聚合功能会变得很麻烦。

【解决方案2】：

我曾在 SQL 和 MongoDB 中工作过。

MongoDB

From my experience MongoDB is best suitable when you follow agile methodologies 
wherein you don't really know what your JSON object will have to contain.

SQL

SQL will be best suitable where JSON object is not going to be changed, like 
for bank projects, where you know the exact format of JSON which is never going 
to be changed.

差异

Why I am saying this is, whenever we need to add some extra fields or need to 
link some fields with primary, foreign keys it would be pain and wouldn't know 
what could go wrong.

Wherein in MongoDB if you need to reference some field you will just need to 
add key ref with that field and you are done.

MongoDB

MongoDB would be great when one of your key from one JSON object is to be 
referenced to mutiple JSON object by just adding that field name in ref (ref: 
'user')

请投票给这个答案，以便有需要的人找到这个答案，并在 MongoDB 最适合他们的时候得到。

【讨论】：

【解决方案3】：

我认为在以下情况下首选 SQL：

关系完整性（数据完整性）至关重要
数据更新频繁
实体之间存在明确和/或牢固的关系

MongoDB 更适合：

水平缩放/分片
复制 SQL 数据以避免在生产中进行代价高昂的查询（某些替代方案可能更好）

我会说，当不确定时使用 SQL。当您改变主意时，从 SQL 迁移到 NoSQL 比从其他方式迁移要容易得多。

【讨论】：

【解决方案4】：

当您拥有大量无模式数据时。当您的数据和用户将无限增长并且您需要可扩展的云数据库解决方案时。当您在 CRUD 的某些方面需要更高的性能提升时。当您的软件堆栈基于 JS 时。您可以在此 youtube 视频中查看其他原因 https://youtu.be/K8xsuFgCRkU

【讨论】：