Node.js 操作mongodb好不爽,有没有什么好的代码?
发布于 12 年前 作者 fiture 22145 次浏览 最后一次编辑是 8 年前

Node 先要 require(‘mongodb’) 然后获取DB 对象 然后获取ObjectID

然后再new 一个db connection 还要设置是否一直链接

然后再DB open 然后再嵌套查找,然后再在callback里面返回数据 然后返回数据后,还要mongodb.close()

有没有好点的代码??囧 不想用:mongoose 之类的东东。

38 回复

嗯,正在看。感觉还不错。

为什么 Mongoose 又被抛弃了…

= =前面不配置你怎么连接数据库,我就比较喜欢mongoose,尤其是在存数据的时候,数据类型 在配置的时候就定义好了.

嗯,用是可以用。而且用起来挺爽的。只是想学习下。

试试mongolian,不过我还是建议用Mongoose,毕竟带了ODM的功能,用起来方便许多。

做过后端的话都应该想到ORM框架啊,mongoose不就很好么

要ORM还用什么mongodb啊?

@imzshh 那mysql、oracle、db2提供了ORM?

nodejs的技术欢迎加群聊262658247

这个不是库的问题,是异步编程的问题

推荐async库,里面的waterfall可以解决你的问题

另外老赵的windjs我没太深入用,但也是用来解决此类问题的

喵的, 看来现在必须求代码了, MongoSkin 怎么好?

@a272121742 关系型数据库才需要OR/M。虽然mongodb是最很接近关系型数据库的NoSQL数据库,但毕竟它的Schemaless也是一大特点,而mongoose却要求定义Schema,这不是很搞笑吗?如果不需要Schemaless,又何必用mongodb? @jiyinyiyong Mongoose和mongoskin不是哪个好的问题,而是它们的设计理念就不一样吧。最好是作者来讲讲。

经验有限,师请雅正。一下是我个人的观点: 其实我并不觉得只有关系型数据库才能使用ORM,对象关系映射中的对象并不能笼统的指向为面向对象的关系型数据库。大多数程序语言都是面向对面或者基于对象,而数据库存储的都是数据,数据库端的CRUD都需要使用数据库提供的操作语言,而服务端要使用数据库的语言进行操作,程序语言的单一性受到了干扰,程序开发人员面临着其他语言的学习困扰。ORM用程序语言将数据库模型封装在程序中,让程序员以核心向心力的去关注程序的业务逻辑,由业务逻辑的改变而影响真实的数据。

@a272121742 你说的没错。但是你为什么要用mongodb而不是mysql?

那官方的 mongodb 模块问题主要在哪儿, 有具体的代码能介绍下么?

@a272121742 比较赞同你的话。

补充一点就是。模式自由的真正应用不是那么大。如果为了项目的 直接性 简洁性 统一性还是需要模式的。

不然的话 数据库操作的代码会分布在代码的各处。当然可以把这些代码集中起来。既然集中起来了,那不就等于是模式来么? 为什么不直接用模式定义?

其实就用mysql挺好的。我用了mongodb就蛮后悔的了。mongodb在很多地方的性能其实不怎么高的。例如分页的时候。mongodb权威指南的上说通过其他查询条件代替直接skip的分页。但是这个不太现实。因为很多时候没办法直接替代。就算能替代,你也要面临着很复杂的逻辑。

所以在mongodb不够快的时候,你要想办法在mongodb上面加一层缓存。例如redis,或者是memcache.等等。

但是mongodb已经是内存大户了。你再加一层缓存。就很 郁闷了。还有就是在构造缓存的时候mongo没有mysql来得直接 mysql直接md5(sql)作为key,results作为data存到memcache里面就搞定了。

所以还不如mysql + 缓存来得直接 方面

综上 mysql + 缓存 在速度上应该够了,内存开销也能接受 而且也蛮直接的 而且还不用去学新的东西。而且在设计上,大部分人已经掌握mysql了,没有跨度,不用摸索新的数据库的“设计模式”

@imzshh 1.mongoodb提供schemaless的数据存储,操作类似javascript 2.当时没有找到mysql对应的orm模块,而mongoose提供了,在此基础上进一步封装,使其更加完善,并使用习惯了。

@jiyinyiyong 原声的mongodb操作链条化,业务多的话回调迭代就会比较多,而且参数配置比较麻烦。ORM提供的有一个重大而且简单的功能就是能雾化模型,将数据库的数据转化到程序语言或脚本中。我们知道在一个应用或者程序中,数据是必须做验证的,前端、后端、数据库段都要做。但是三个地方如果都做,未免太麻烦了,ORM提供一种简单的配置方式,用文字脚本书写数据库验证规则,在操作数据库的时候,一方面能自动验证,一方面操作的对象能自动影响数据库。这样,业务层就不会出现冗余的业务逻辑。我们用文字流程来说明转账业务: 1.A减钱 A.setMoney(-1000); 2.B加钱 B.setMoney(+1000) 虽然步骤很简单,但是验证的过程却很麻烦,1.检测用户是否正常,2.检测金额是否充足,3.操作异常要进行事物回滚。如果在业务层要进行这些非实际业务的操作,那代码量将是比较大的,而且职责不够单一,应用AOP的思想,我们在实例化A、B或者调用他们的方法前都会去读取数据库配置文件来自动检测的话,那么验证的过程就能与真实业务降低耦合,这样我们在业务层看到的就是简单真实的业务了,而逻辑层已经被分离,可以复用,独立的层也方便修改。

@darklowly 同意,其实orm框架或者手动封装的数据库,无非就是将经常使用的数据库操作封装起来成为一个模块,提供公共的接口给程序员,程序员不需要关注内部实现,只需要使用通俗易懂的程序语言和程序操作来操作对象,就能在orm框架的帮助下影响数据库的数据。勤奋的程序员往往不爱封装,而懒惰的程序员总是抱怨代码、模式重复,于是他们就会进行封装,让自己今后的开发变得更加“懒惰”。

@a272121742 哦, 也真是啊. 受教了.

mongodb的连接不关闭, 持续连接应该没问题吧, 有没有这方面的专家.

其实都差不多,看怎么用了,我现在在用mongoskin

我一直用mongoskin, 觉得比较符合个人习惯,哈哈

想要小巧好用的话,mongojs也可以一试

直接操作mongodb的存储过程就好,很简单的事情

试用了一下,mongo-lite的感觉最好。 另,mongodb返回的就是js对象,有必要用orm么?

db.posts.insert({title: ‘first’}, function(err, doc){}); 跟在command界面的感觉一样,太舒服了

换用mongoskin了,mongo-lite不支持连接池,多个更新同时进行的时候,就会报错。 在mongoskin中使用bind后,也能使用和mongo-lite一样的代码风格

另,同时更新多个文档时,必须删除待更新对象的_id,否则总是失败

@williamdu 同意你的观点。mongodb的数据读出来就是json,和js天生融为一体,代码里和命令行里可以互相印证结果。前端发送json数据过来,后端直接塞入数据库查询、插入、更新。用orm模型的mongoose还不如自己封装一个db模块,太过集成化的工具有时候会使人有依赖性。

楼上大家的观点,在大公司大团队中,确实沟通成本比较高,需要统一开发的话,还是要统一工具和模型。对于个人开发者,或者小团队而言,精简、高效、直接,也许会比较适用。 个人见解

至于mysql+redis,已经尝试过,不是很给力。前端发送的json数据都被打散了,还需要构造大量的数据类,方便操作,读写缓存等。redis和mysql之间的缓存底层也是自己开发的,为了数据一致性费了很大功夫。

mongolian vs mongoskin?

这么老的帖子也顶。

以前一直mongoskin,后来发现他们也不怎么维护了。 玩一玩,用mongolian和 mongoskin确实足够了,等静下来,准备脚踏实地的写一个web app时,复杂性,就不是一个Blog那么简单了。

复杂性上来了,必要的数据结构文档最好写下来的,一旦落实到文档上,你会发现文档可以用mongoose写。 数据校验什么的,mongoose也可以很好的支持,何乐而不为呢?

一直都这么用,db连接最好在整个node运行期,推荐采用连接池来平协同工作。

回到顶部