@roamlog 是什么原因？（现在遇到这些事我都不去想原因了 囧

3年出国

@chuangbo 考谱

会员参加协会是想看到不一样的东西的，不用就着他们

住处网速杯具，明天到公司载。

发型版升级是惊喜打包，滚动升级要不一成不变要不折腾多多

xmpp 用于底层协议不错

都free了靠什么发展呢？

我觉得不关注员工感受的公司或团队是做不出好的产品的。

当然楼主的情况不同，是自发的冒险者精神，不过还是建议趁有假期让身体放松一下。

我在家写代码，搞自己的小项目。

这个阶段适合看 《写给大家看的设计书》，可以发现很多不对劲的地方为什么会不对劲

@cngithub 翻了下这本书与 Ruby on Rails 相关的第6章，牵涉 Rails 负面的就这句：

page-171

“……可是，决定 Rails 生产效率的并不仅仅是 DRY 或是 CoC，而主要是利用了 Ruby 的元编程能力，几乎可以说达到了恶性滥用的程度……可是，正是因为这样的彻底发挥才实现了 Rails 的强大功能……”

其余描述猴子补丁是针对猴子补丁的范围，而不是针对 Rails，而且 Rails 显然是一个猴子补丁的成功范例。所以说 “用Ruby作者Matz的话来说，Rails充斥了太多猴子bug” 我觉得不妥。

确实 Rails 3.1 更新了很多东西，直接上 Rails 可能会遭遇很多魔法，但是我觉得不用低估好的程序员的适应能力。Rails 的示范作用是很明显的，比如 method_missing 在单单看书或者自己写的时候，参照不到好的 api 设计，看了 ActiveRecord 的动态 find_by 方法才会了解到这个技术应该怎么用（Metaprograming Ruby 就是拿 ActiveRecord 做例子）。

Matz 疑惑为什么 Ruby 在 Rails 前面也在 page-171 找到了。

@cngithub 求Matz原话出处

"现场系统"……

@avatasia 是啊

@avatasia 关系数据库的领域 ：)

@avatasia 我不明白为什么要更新1000万条list。

user 有个 _id，交易记录方面记录 user_id 就行了。更新 user 或者 更新交易记录都不涉及更新另一个数据集合。

或者说你需要一次用join查询查出交易记录和用户信息，那么Mongodb做不到，需要多一次查询，先查交易，再查用户（或者反之）。

组那里大致就这样设计，不过存放最好用id不用组名。不要觉得在user里存组id是重复，因为少了一个关联表，其实就是把关联表拆散到文档里。

@avatasia

A.b_ids -> B

改变为

A <- B.a_ids

哪头开销小放哪头。

另外我没理解清楚“组”是什么？

@avatasia 不太了解你的具体应用，你提到的地方两类数据库处理区别不大啊。

@kuno 描述的这些功能在储存端不成问题，把关联ID作为list存在某个实体的文档那端就行了。做Timeline（多态）的时候，你会发现Mongodb的无模式提供了大大的便利。

或者这样说，Mongodb 没有关联查询，但是是可以储存和查询关联数据的。

@kuno 描述一下需要什么样的关系？

@kuno 用关系数据库的思维去想，很糟糕，因为没有JOIN查询。

但是用Mongodb的思维去想，非常合适。