MongoDB SQL is Agile

bhuztez · 2013年01月10日 · 最后由 hooopo 回复于 2013年08月23日 · 3047 次阅读

http://lucumr.pocoo.org/2012/12/29/sql-is-agile/

我也是这么认为的。最开始的时候,总是要先搞清楚数据本身的约定以及数据之间的联系,第一步总是要normalize的,schemaless在这里并不能带来什么帮助,反而更麻烦了。从这个角度来看,MongoDB显然不适合用来开发原型。

假如你不熟悉SQL,可以看看这个博客

http://database-programmer.blogspot.com/

接着才是RDBMS处理不好的地方要denormalize,有必要的话再引入别的类型的数据库

你可以放弃几乎所有JOIN,获得接近线性扩展的集群能力。这是MySQL NDB,Mnesia之类的数据库了。

也可以预先定义好需要哪些JOIN,把相关数据放在一起,从而为这些JOIN优化。Google F1和Oracle的Table Cluster就是这么干的。有没有开源实现,我还没了解过,你可以来补充一下。

http://research.google.com/pubs/pub38125.html http://docs.oracle.com/cd/E11882_01/server.112/e25789/tablecls.htm#i25478

再后面就得等着被CAP坑了。

http://blog.nahurst.com/visual-guide-to-nosql-systems

CouchDB用来做aggregation,通过放弃consistency,换取用空间换时间的机会 Memcachedb之类的用来做缓存 BigTable之类的,没用过,据说很有用

共收到 6 条回复

相反我认为mongodb很适合在原型阶段作为数据存储,就是因为schema free。

什么叫原型,为什么要使用原型。 就是很多对象,很多流程还不确定,需要原型来验证,帮助梳理,帮助思考,迅速的使用可见的原型来验证一些事物,有一个直观的可见对象。

在原型的时候,你根本确定不了那些数据需要保存,数据的那些属性需要保存,今天可能是这几个,明天可能是另外的,带来的数据库结构维护,会很痛苦的。

熟悉什么用什么

#1楼 @woaigithub

schema又不是不能变啊 ...

schema就是帮助梳理,帮助思考

@hooopo LS说得好。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册