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之类的，没用过，据说很有用
相反我认为mongodb很适合在原型阶段作为数据存储，就是因为schema free。
什么叫原型，为什么要使用原型。 就是很多对象，很多流程还不确定，需要原型来验证，帮助梳理，帮助思考，迅速的使用可见的原型来验证一些事物，有一个直观的可见对象。
在原型的时候，你根本确定不了那些数据需要保存，数据的那些属性需要保存，今天可能是这几个，明天可能是另外的，带来的数据库结构维护，会很痛苦的。
熟悉什么用什么
@hooopo LS说得好。