MongoDB、Mysql和关系

我正在创建一个在线聊天

上下文（如果需要）：

到目前为止，我使用PHP/MySQL和AJAX来完成这项工作，但这并不是一个健康的解决方案，因为我一直使用“拉”类型的应用程序，担心可伸缩性。 我读过关于“push”方法的备选方案，似乎我的选择是有限的，不包括PHP。 如果Websockets集成在每个浏览器中，那么它可能是一个非常有趣的选项，但事实并非如此（对于大多数实现Websockets的浏览器来说，它在默认情况下是禁用的）。 长轮询也可能是一种选择，但它涉及其他问题，如并发打开连接的数量，这也可能会杀死您的web应用程序

这就是为什么违背我的意愿，我认为我唯一可行的选择是使用服务器端javascript（node.js+now.js将是我当时的选择）

也就是说，我可能也需要重新考虑数据库的使用。 我需要保存每个用户的存储数据，并将这些用户链接到他们提交的消息。 如果是由推送系统驱动的聊天引擎，MySQL仍然是一个有价值的选择吗？ 我读过关于NoSQL数据管理的文章，似乎MongoDB是node.js的一个很好的补充

我的两个问题：

对于实时web应用程序，有没有什么理由让我最好改用NoSQL系统（我需要从头开始学习），而不是MySQL（我已经知道）呢

假设在MySQL中：

• 我有一个名为user（user\u id\u p，username）的表
• 我有一个名为messages的表（message\u id，message，user\u id\u f）
• 我想进行一次查询，以获取与用户名“omgtheykilledkenny”关联的所有消息

很简单，但我如何用MongoDB及其系列理念实现这一点

谢谢你的帮助

使用node.js/MongoDB很酷，因为Mongo的文档结构已经是JSONish，所以您不必将查询转换为JSON。如果您已经了解JavaScript，那么您就可以开始学习MongoDB了。Mongo的读写扩展非常容易，速度非常惊人，尽管我在单个系统上看到一些MySQL基准测试与Mongo相比非常好——当您开始需要多个盒子时，它确实非常出色

假设您有一个单独的messages集合，并且您已经知道用户的id，您可以执行以下操作：

db.messages.find（{user\u id:ObjectId（…）}）

更新：如果您不知道用户id，那么您需要进行两次查询，是的（除非您按照另一个答案中的建议使用嵌入式数组——不过，我建议在这种用例中不要这样做，因为您将查询整个文档/消息列表，甚至只显示一个子集）。显然，根据您的使用情况，如果您有用户名，您也可以将用户id放在手边，用于类似的情况。如果是客户端输入，则用户名无效

---

Update2：如果您有唯一的用户名，可以将用户名作为users集合的_id，以避免此问题。大多数人可能会建议不要这样做，但它有一些明显的缺点，例如使更改用户名变得更加困难。

您无法在MongoDB中执行连接，因此无法实现第二个要求。Mongo这样做的方法是在用户集合中嵌套消息：

{用户名：'abc'，消息：[……]}

或者使用refId，这是连接和嵌套文档之间的一种折衷方法：

就从MySQL切换到Mongo而言，您不必完全抛弃MySQL。存在一个比另一个更合适的用例。如果合适的话，您可以在系统的不同部分同时使用这两种方法。就我个人而言，过去我在很多方面都使用过MySQL，现在我在一个大项目中使用MongoDB。我发现移动非常容易，因为使用MongoDB驱动程序非常容易，而且MongoDB站点总体上非常适合文档编写

---

您可以使用前端的JSON_encode和JSON_decode转换JSON，并使用MongoDB的PHP驱动程序查询和插入/更新数组，因此可以说它比MySQL更直观、更易于使用。这只是一个习惯的问题。

#1：是的-速度和规模是两个原因#2：使用mongo做你想做的事情很容易。你做过RTFM吗？你有什么特别的问题吗？还是你想让我们教你？请相信我，我做过RTFM，但我就是不明白。我就是找不到如何在集合之间建立关系。这对于有经验的开发人员来说可能是显而易见的，但对我来说没有意义。在同一个集合中进行简单的查询是可以的，但是在两个集合之间组合数据以获得响应是我无法理解的。到目前为止还没有发现任何与此相关的东西。除此之外，我相信我的问题非常具体。谢谢韦斯·弗里曼。我的第一个答案已经完全回答了。至于第二个，我不确定。在您的示例中（我很清楚地RTFM'ed），它假设它会给我提供的用户id的消息，但不会给我特定用户名的消息（在另一个名为“users”的集合中可用）。有两个查询（我查询这个用户名的id，然后查询我检索到的用户id的消息）很容易做到这一点，但是有一个并且只有一个查询，我将如何做到这一点？这就是我的观点，谢谢。我想把你们的两个答案都设置为有价值的，但似乎只有1个问题是允许的。关于这个问题，我不能在会话中保留任何用户的id，因为我可能需要任何用户的id（或者没有）。对于用户名作为id，它不会回答我的问题，因为这里的用户名就是一个例子。我需要它，但我也需要附加到消息，用户性别，出生日期，头像等。这些是用户相关的，而不是消息相关。唯一的共同点是