关键性业务，是可以抽离的。Mongodb 还是一把很不错的库。

自从 Postgres 有了 hstore，mongo 基本不想碰了

自从 MySQL 给收购后，就一直 PostgreSQL

说到底就是觉得 MongoDB 不能存储关系而矣，感觉是水平不行，没有外键可以使用有模式的框架做出外键，而且也不一定一直会没有的吧，Mongo 才出来几年……

我好像刻几年前有个人开博说：MongoDB 有多糟糕， 后来他自己承认是开玩笑，甚至很多不好的场景是他自己虚构的。

@knwang @xds2000 @xstmjh @imlcl @newghost http://www.csdn.net/article/2012-11-15/2811920-mongodb-quan-gong-lue

呵呵。。我昨天也在纠结 join 呢，但是我后来发现，何不做个冗余，干嘛非要 join 呢。。感觉 mongo 很好啊

@knwang 我以前工作过的一个项目很类似，开始看的时候很适合 Document types, 越到后来业务需求越复杂越是把 Mongo 硬当作关系数据库用 这纯粹就是用惯了 mysql 的人在用 mongo，要用 mongo 真的要研究一下他的设计思想。这个很重要滴。说~！

各有秋千吧 T_T

我觉得你应该先考虑下把业务逻辑放在数据库还是在程序里

#7 楼 @jarorwar 这个项目的带头人是 Mongoid 的第一开发者。

要用 mongo 真的要研究一下他的设计思想

这不是一个技术上的错误，而是一个对业务预期／沟通的问题。和 Sarah Mei 写的是一样的。

#10 楼 @knwang 您这是想说明什么啊。mongodb 不是适合所有领域啊~！

#11 楼 @jarorwar

想说明 这不是一个出于技术无知的错误。参与的程序员对 Mongo 非常了解。

谈论这个咩意思吧，主要是看用的人的心态和水平

#12 楼 @knwang 哦。不懂。说错了勿怪。可以说是一个选型的错误吧~！我整两个 collection 的 join 整了了好久，，都快把自己整晕了（不是很熟悉 mongodb），然后果断放弃，加了冗余，效率明显提高~！，

@jarorwar 加冗余简单，维护难。。。

#15 楼 @zhangjinzhu 恩。其实我们的比较简单，我说下吧： 原来是 a 持有对 b 的引用，即外键，所以在 a 的 collection 中存了 b 的 id，业务中有一个业务需要 a 和以及 b 的部分字段才可以完成，刚开始直接用 a.b.column 来获取，但是后来这个业务的查询越来越多，甚至要批量批量的查询。我发现这种效率低下了，所以就把对应的 b 中的两个字段直接放到 a collection 中，这样，我只需要查出 a 就可以完成业务了。。但是这样造成的问题就是，我在 save 或者 update 的时候就需要去更新和维护 a 中对应 b 的 column，因为 update 操作并不是非常频繁，所以，我觉得是可行的。就暂时这么搞了~！

人家已经拿到几亿的投资。

#14 楼 @jarorwar

问题恰恰是当时的项目几乎是 Mongo 的最佳用例 － 从数据本身的结构，完全是孤立的深层次的 Documents, 而没有任何需要 cross references 的地方，不需要任何冗余; 项目需要支持非常大的 scale，深度的 Partition 和高可用，不需要灵活的分析，简直就是 Mongo 的案例型的项目。

前面很久的时间用 Mongo 非常舒服，mongoid 这个库也就是从这个项目里面抽取出来的，但是做到两年以后就越来越感觉别扭了，应为很多的新的硬性需求和最前面的数据结构假设非常不一样，也是可以实现，但是就觉得 Mongo 不是方便，而是处处别扭。

和 Sarah Mei 文章里将的案例非常相像。

#18 楼 @knwang 哦。。如此的话，用 mysql 什么的也不一定见得好多少吧~！因为您的业务已经达到非常复杂了。也不是任何数据库都能完美胜任的了。呵呵。。

#17 楼 @ruby_sky 哇塞。。与伟人对话~！

呵呵

#20 楼 @jarorwar 伟人都是已经死了的。我是吃青菜小鸟，简称菜鸟。

MongoDB 的 schema free 特性通过写冗余字段确实可以大大减少相对于关系型数据库的查询次数，但是如果冗余的东西多了，维护起来太难受了。

从关系型数据库转到 MongoDB 的新手 (我) 刚开始都会把 MongoDB 当做关系型数据库来用。说白了，还是没理解。

@jarorwar 嗯，不过等冗余变的太多的时候，维护冗余的逻辑会遍地都是。。。然后会出现各种莫名的 bug，因为冗余忘记更新了。。。

mongodb 看似比 SQL 简单，但和封装 SQL 的 ORM 相比，还是有些差距，因此还不如挑个好的 ORM 用呢

@jarorwar 例如？

#26 楼 @jarorwar mongodb 很强大没人否认，我个人观点没必要全盘否定，但是也要客观评论，我和 @zhangjinzhu 基本一致，mongodb 自身的灵活性对于应用层的维护是灾难。

说白了吧，是双刃剑，看场景和需求。

@jarorwar mysql 存序列化后的 json 就可以了么，只是这些动态增加的字段搜索可能是个问题，但如果你想搜索的时候，就在跑程序的时候动态的用 sql 增加一个字段呗，然后赋值到这个字段就好了，也很简单。

你可以用 mongodb 加字段，又没有法律规定你用关系型数据库不可以。

#31 楼 @jarorwar 我说的全盘否定是指

为什么你应该永不用 MongoDB

不是说你。

#30 楼 @zhangjinzhu @zgm 对不起。我错了。。我删帖~！

@jarorwar 纯技术探讨。。。。。又没有人会一直全对。。。

#33 楼 @jarorwar 用得着删帖么. 好吧，下次你的讨论我一概不回复了。

#32 楼 @zgm 这个只是我作为菜鸟，我在遇到 join，感觉快要死掉的时候，我看的一些资料。我怀疑自己的设计有问题。所以，我把这篇文章当作 mongo 使用的一个指导而已！没有别的意思~！

#30 楼 @zhangjinzhu MongoDB schema free 特性绝不是 Mysql 用 JSON 序列化之后能比的...

#37 楼 @zgm 心小脸皮薄。勿怪勿怪~！

@zgm 嗯，我了解一些，上面也提过，例如可以搜索之类的。但有得有失，只能是在各种对比后的取舍。

yay!

mongodb 很适合这种国内行政机构的数据，省市县区乡逐级嵌套，而且动不动就是几亿的数据量，用 mysql 就得弄很多表相互关联，而且分表的话各个地区的数量级又差别悬殊，有的城市象重庆，北京几千万，象西部省市的一个省才几百万

我早就说了，因为 SQL is Agile

为什么你应该永不用 java? 为什么你应该永不用 web？ 为什么你应该永不用 手机？ 我知道里面肯定有合乎情理的理由，但还是反感这样的标题党，无论他是大牛还是小楼咯，这标题天生就是为引起争端而生的，往往也无异于进步。

#41 楼 @yakczh 用什么数据库和数据量真的没有太大关系，数据库本质就是为不同业务需求提供最高效的读写访问。

MySQL 和 PostgreSQL 等关系型数据库重在正交性，对于一般应用这个是首选。MongoDB 等 NoSQL 重在横向扩展和其他特别的优化。

#44 楼 @mvj3 得确 很多人选择 mongdb 的原因是横向扩展是他本身的一部分，理解实施简单，不像 pg/mysql 要部署第三方工具

我曾经很长时间考虑在进销存/erp 中是否使用 mongodb, 但结论目前还是不合适

mongodb 比较适合文档和分析型系统。交易型的不太合适。