哪个数据库适合我的应用程序mysql或mongodb？ 使用Node.js，Backbone，Now.js

我想使用前端：docs.google.com（没有它的API，完全在我自己的服务器上）使用前端：骨干后端：节点

你认为哪个数据库更好？ mysql或mongodb？ 应该支持良好的可扩展性。 我熟悉MySQL的PHP​​和我会很高兴，如果答案是MySQL。 但是我看到很多教程，他们使用mongodb，为什么他们使用mongodb没有mysql？ 我应该使用什么？

任何人都可以给我链接一些示例应用程序（与源）build立使用骨干，节点，MySQL（或mongo）。 或至less应用程序。 与节点和MySQL

谢谢

Answer 1

使用MongoDB，您可以存储 JSON对象并将它们完整地检索出来，因此您并不需要一个ORM层，而且您可以花更less的CPU时间来回转换数据。 MongoDB背后的开发人员也使得数据库水平扩展为更高的优先级，并允许您运行任意的Javascript代码来预处理数据库端的数据（允许数据的map-reduce样式过滤）。

但是你为这些收益损失了一些：你不能joinlogging。 实际上，您存储的JSON结构只能通过SQL中的连接来完成，但是在MongoDB中，只有一个结构用于数据，而在SQL中可以以不同的方式进行查询，并且可以更容易地以不同的方式表示数据，所以如果您需要对你的数据库做很多分析，MongoDB会更难。

在我看来，MongoDB中的查询语言比SQL更“粗糙”，部分原因是因为它不太熟悉，部分原因是查询function“随意”放在一起，部分是因为它使JSON有效，几种做同样的事情的方式，有些是比其他方式更有用或者定期格式化的更老的方式。 数组和子对象types比SQL简单的基于行的devise增加了复杂性，因此语法必须能够处理包含您定义的一些值的数组的查询，包含您定义的所有值， 只包含您定义的值，并且不包含您定义的任何值。 对象键和它们的值也有相同的区别，这使得查询语法更难掌握。 （虽然我可以看到边缘情况的需要，但$where查询参数（它接受在每个数据logging上运行的javascript函数并返回一个布尔值）是Siren歌曲，因为您可以轻松定义您的对象想要返回或不返回，但必须在数据库中的每个logging上运行，不能使用索引。）

所以，这取决于你想要做什么，但是既然你说这是为了Google Docs克隆，你可能不关心任何表示， 只是文档表示，而你可能只是基于文档来查询ID，文件名或所有者的ID /名称，在查询中不会太复杂。

然后，我会说能够把你的用户正在编辑的文档的JSON表示，并将其放入数据库，并自动索引这些重要的领域，是值得学习一个新的数据库的代价。

Answer 2

我也在为这个select而努力，看看使用MongoDB创build它的非工作任务。 所以我的2美分是：

1. 正如David所说，在MongoDB中存储和检索分层对象（可能是文档）比较容易。 如果你想存储比16Mb更大的文件，这变得更加复杂 – MongoDB的答案是GridFS。

2. 在文件夹，组织中组织文档，跟踪哪个用户拥有哪些文档以及他/她提供了对他们的访问权限对于MySQL来说绝对是比较容易的 – 您可以利用强大的SQL查询和连接等优势，构build在EXPLAIN优化，触发器，函数，存储过程等MongoDB是远不及。

那么是什么原因妨碍你使用两个MySQL来组织文档，MongoDB存储一个由id标识的文档集合（或者几个集合 – 每个文档types一个集合）？ 在我看来，最好的select和在一个应用程序中使用两个数据库不是一个问题，真的。

MySQL将存储用户，组，文件夹，权限（无论你喜欢什么），并为每个文档存储对集合和文档ID的引用（MongoDB有一个特殊的格式 – DBRefs）。 MongoDB将自己存储在集合中，如果它们都小于16MB，或者集合中的文档的预览和元数据以及GridFS中的整个文档。

Answer 3

大卫提供了一个好的答案。 一些东西添加到它。

1. MongoDB的灵活特性允许轻松灵活/迭代开发。
2. 像node.js这样的MongoDB本质上是asynchronous的，在asynchronous环境中工作得很好。
3. Mongoose是一个很好的ODM（对象文档映射器），使用Node.js处理MongoDB感觉非常自然。 与ORM不同，这是一个非常薄的层次。

对于Google Docfunction，MongoDB提供的灵活性和非常丰富的数据结构感觉更好。

你可以通过searchmongoose，node和MongoDBfind一些很好的示例文章。

这是一个也使用backbone.js和看起来不错http://mattkopala.com/blog/2012/02/12/getting-started-with-nodejs/