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

which database suits my application mysql or mongodb ? using Node.js , Backbone , Now.js

提问by user1305989

I want to make an application like docs.google.com (without its api,completely on my own server) using frontend : backbone backend : node

我想使用前端：骨干后端：节点制作一个像 docs.google.com 的应用程序（没有它的 api，完全在我自己的服务器上）

What database would u think is better ? mysql or mongodb ? Should support good scalability . I am familiar with mysql with php and i will be happy if the answer is mysql. But many tutorials i saw, they used mongodb, why did they use mongodb without mysql ? What should i use ?

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

Can anyone give me link for some sample application(with source) build using backbone , Node , mysql (or mongo) . or atleast app. with Node and mysql

任何人都可以给我链接一些示例应用程序（带有源代码）使用主干、节点、mysql（或 mongo）构建。或至少应用程序。使用 Node 和 mysql

Thanks

谢谢

回答by

With MongoDB, you can just storeJSON objects and retrieve them fully-formed, so you don't really need an ORM layer and you spend less CPU time translating your data back-and-forth. The developers behind MongoDB have also made horizontally scaling the database a higher priority and let you run arbitrary Javascript code to pre-process data on the DB side (allowing map-reduce style filtering of data).

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

But you lose some for these gains: You can't join records. Actually, the JSON structure you store could only be done via joins in SQL, but in MongoDB you only have that one structure to your data, while in SQL you can query differently and get your data represented in alternate ways much easier, so if you need to do a lot of analytics on your database, MongoDB will make that harder.

但是您会因为这些收益而损失一些：您无法加入记录。实际上，您存储的 JSON 结构只能通过 SQL 中的连接来完成，但在 MongoDB 中，您的数据只有一种结构，而在 SQL 中，您可以进行不同的查询，并更容易地以其他方式表示数据，因此如果您需要对您的数据库进行大量分析，MongoDB 会使这变得更加困难。

The query language in MongoDB is "rougher", in my opinion, than SQL's, partly because it's less familiar, and partly because the querying features "feel" haphazardly put together, partially to make it valid JSON, and partially because there are literally a couple of ways of doing the same thing, and some are older ways that aren't as useful or regularly-formatted as the others. And there's the added complexity of the array and sub-object types over SQL's simple row-based design, so the syntax has to be able to handle querying for arrays that contain someof the values you defined, contain allof the values you defined, contain onlythe values you defined, and contain noneof the values you defined. The same distinctions apply to object keys and their values, and this makes the query syntax harder to grasp. (And while I can see the need for edge-cases, the $wherequery parameter, which takes a javascript function that is run on every record of the data and returns a boolean, is a Siren song because you can easily define what objects you want to return or not, but it has to run on everyrecord in the database, no indexes can be used.)

在我看来，MongoDB 中的查询语言比 SQL 的查询语言“更粗糙”，部分原因是它不太熟悉，部分原因是查询功能“感觉”随意组合在一起，部分原因是为了使其成为有效的 JSON，部分原因是字面上有一个做同一件事的几种方法，有些是较旧的方法，不像其他方法那么有用或格式不规则。与 SQL 简单的基于行的设计相比，数组和子对象类型增加了复杂性，因此语法必须能够处理对包含您定义的某些值、包含您定义的所有值的数组的查询，仅包含您定义的值，并且不包含任何值您定义的值。相同的区别适用于对象键及其值，这使得查询语法更难掌握。（虽然我可以看到对边缘情况的需求，但$where查询参数采用在每条数据记录上运行的 javascript 函数并返回一个布尔值，这是一首 Siren 歌曲，因为您可以轻松定义您想要的对象返回与否，但它必须在数据库中的每条记录上运行，不能使用索引。）

So, it depends on what you want to do, but since you say it's for a Google Docs clone, you probablydon't care about any representation butthe document representation, itself, and you're probablyonly going to query based on document ID, document name, or the owner's ID/name, nothing too complex in the querying.

因此，这取决于您想要做什么，但是既然您说它是针对 Google Docs 克隆的，那么您可能不关心任何表示，而是文档表示本身，并且您可能只会根据文档进行查询ID、文档名称或所有者的 ID/名称，在查询中没有什么太复杂的。

Then, I'd say being able to take the JSON representation of the document your user is editing, and just throw it into the database and have it automatically index these important fields, is worth the price of learning a new database.

然后，我会说能够获取用户正在编辑的文档的 JSON 表示，并将其放入数据库并让它自动索引这些重要字段，这是值得学习新数据库的代价。

回答by esp

I was also struggling with this choice looking at the hype created by using MongoDB for tasks it was not built for. So my 2 cents are:

我也在为这个选择而苦苦挣扎，看看通过使用 MongoDB 来处理它不是为它构建的任务而产生的炒作。所以我的 2 美分是：

1. Storing and retrieving hierarchical objects, that your documents probably are, is easier in MongoDB, as David says. It becomes more complicated if you want to store documents that are bigger than 16Mb though - MongoDB's answer is GridFS.

2. Organising documents in folders, groups, keeping track of which user owns which documents and who he/she provided access to them is definitely easier with MySQL - you have the advantage of powerful SQL queries with joins etc., built in EXPLAIN optimization, triggers, functions, stored procedures, etc. MongoDB is nowhere near.

1. 正如大卫所说，在 MongoDB 中存储和检索分层对象（您的文档可能是）更容易。如果您想存储大于 16Mb 的文档，它会变得更加复杂 - MongoDB 的答案是 GridFS。

2. 使用 MySQL 在文件夹、组中组织文档、跟踪哪个用户拥有哪些文档以及他/她为谁提供了对这些文档的访问权限，使用 MySQL 绝对更容易 - 您拥有强大的 SQL 查询和连接等的优势，内置 EXPLAIN 优化、触发器、函数、存储过程等。MongoDB 远不及。

So what prevents you from using both MySQL to organize the documents and MongoDB to store one collection of documents identified by id (or several collections - one for each document type)? It seems to me the best choice and using two databases in one application is not a problem, really.

那么是什么阻止您使用 MySQL 来组织文档和使用 MongoDB 来存储一个由 id 标识的文档集合（或多个集合 - 每个文档类型一个）？在我看来，在一个应用程序中使用两个数据库不是问题，真的。

MySQL will store users, groups, folders, permissions - whatever you fancy - and for each document it will store a reference to the collection and the document id (MongoDB has a special format for it - DBRefs). MongoDB will store documents themselves in collections, if they are all less than 16MB, or the previews and metadata of documents in collections and the whole documents in GridFS.

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

回答by Steve Francia

David provided a good answer. A few things to add to it.

大卫提供了一个很好的答案。一些事情要添加到它。

1. MongoDB's flexible nature permits for easy agile / iterative development.
2. MongoDB like node.js is asyncronous in nature and works very well within asyncronous environments.
3. Mongoose is a good ODM (object document mapper) that makes working with MongoDB with Node.js feel very natural. Unlike ORMs this is a very thin layer.

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

For Google Doc like functionality, the flexibility & very rich data structure provided by MongoDB feels like a much better fit.

对于类似 Google Doc 的功能，MongoDB 提供的灵活性和非常丰富的数据结构感觉更合适。

You can find some good example posts by searching for mongoose, node and MongoDB.

您可以通过搜索 mongoose、node 和 MongoDB 找到一些很好的示例帖子。

Here's one that also uses backbone.js and looks good http://mattkopala.com/blog/2012/02/12/getting-started-with-nodejs/

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