我有一个相当大的应用程序在MongoDB（Mongoose）中存储数据，尽管我的数据绝对是续集，并且可以很好地呈现为带有模式的表。具体来说，我在对象之间有很多关系。所以我需要执行非常深的种群-每个请求总共25个。
一个好方法是为MySQL重写应用程序。然而，在MongoDB上绑定了大量代码。问题是：如果对象之间的关系越来越多，它是否仍然像MySQL一样高效，或者我应该深入代码并将应用程序完整地移动到MySQL？
在这两种情况下，我都使用ORM。现在猫鼬，如果我移动-序列化。
Mongo在处理关系方面真的很高效吗？我的意思是，SQL旨在将表与关系连接起来，我希望它有一些优化。Mongo的关系似乎有点不寻常。所以，我担心从Mongo中收集25个集合的数据或从MySQL中连接25个表的数据的逻辑上相同的查询对Mongo来说可能会更慢。
这是我正在使用的Schema示例。填充字段用*标记。
Man
-[friends_ids] --> [Man]*
-friends_ids*: ...
-pets_ids*: ...
-...
-[pets_ids] -> [Pet]*
-name
-avatars*: [Avatar]
-path
-size
-...
我对关系的想法。让我们想象一下男人应该有[朋友]领域的对象。让我们把它拿出来。
MySQLORM：
蒙戈：
没有对JOIN表的请求。我说得对吗？
所以我需要执行非常深的种群-每个请求总共25个。
一个常见的误解是MongoDB不支持JOIN。虽然这是部分正确的，但也是相当不正确的。现实情况是MongoDB不支持服务器端连接。
MongoDB的座右铭是客户端JOINing。
这个座右铭可能对您不利；应用程序并不总是了解JOIN的最佳方式，因此您必须在MongoDB中非常仔细地选择架构、查询和JOIN，以确保您不会低效查询。
25对于MongoDB来说是完全可能的，这不是问题。问题在于你在做什么JOIN。
这导致：
蒙戈在处理关系方面真的很有效率吗？
让我给你一个例子，说明MongoDB实际上比MySQL更快。
想象一下，您有一个group集合，每个group文档都包含一个user_ids字段，该字段表示为与user集合中的_id字段直接相关的ObjectId数组。
在这种情况下，执行两个查询，一个针对组，一个针对用户，可能比MySQL更快，因为MongoDB不需要使用IO带宽原子地写入结果集来执行常见任务。
话虽如此，任何复杂的东西，您都会被应用程序不真正知道如何使用索引交叉和合并来创建稍微高性能的JOIN这一事实所困扰。
例如，假设您希望在一个查询中通过3 JOINed表分页在3个表之间进行JOIN。这可能会扼杀MongoDB的性能，同时执行起来效率不高。
但是，您可能也会发现这些JOIN无论如何都是不可扩展的，实际上会扼杀您在MySQL上获得的任何性能。
如果ObjectID对象之间的关系越来越多，它是否仍然像MySQL一样高效，或者我应该深入代码并将应用程序完整地移动到MySQL？
取决于查询，但我至少给了你一些建议。
你的问题有点宽泛，但我有两种解释。
第一，你说你有25层深的引用，在这种情况下，使用填充是行不通的。我非常希望这不是你发现自己的困境。转移到SQL也帮不了你，事实是无论如何你都会回到数据库太多次。但是如果这是必须的，你可以使用物化路径模式的变体来解决它，这将允许你在非常深的数据树中更有效地选择子树。请看这里的讨论：http://docs.mongodb.org/manual/tutorial/model-tree-structures-with-materialized-paths/
另一种解释是集合之间有25个关系。假设在这种情况下，Mongo中的每个英文字母都有一个集合，集合A中的文档引用了集合B-Z中的一个或多个文档。在这种情况下，你可能没问题。Mongoose填充允许你填充多个引用路径，我怀疑它是否有一个限制，低至25。所以你会做类似docA.填充（“B C… Z”）的事情。在这种情况下，移动到SQL本身也没有帮助，你仍然需要连接多个表。
当然，你最初关于这一切都可以在SQL中完成的陈述是有效的，这里似乎没有使用（或不使用）Mongo的具体原因，只是看起来事情是这样做的。然而，看起来你是否使用非关系型数据库或SQL方法并不是你是否会看到效率低下的决定因素。相反，这是你是否在你选择的任何解决方案中正确建模数据。
