@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的思维去想，非常合适。

一个月五次编辑一次删除

蓝钻会员无限编辑，红钻会员无限删除，紫钻会员可以删掉别人的贴，绿钻会员可以限时置顶……

@hooopo @Los 逛S1论坛我学会了“反串黑”这个词和一密顶十黑这个道理。

@Mr_Vangogh 又被顶上来了，我做个丑人好了。v2ex的代码之前已经讨论过好几次了，所以已经不太讨论了。

http://www.v2ex.com/t/6892

总的来说站主知道代码需要改进，也在重构中，不过似乎进度比较慢。

如果支持中文就需要用户填多一个urlname了。

求问 @Livid 现在还在免费GAE阶段么？有缩手缩脚么？

后台的事其实无所谓吧，就算用文件储存也能把网站写出来。无所谓栽进去，写网站不是难事。

@kongruxi http://www.coffeepowered.net/2010/02/17/serving-files-out-of-gridfs/ 好像是这篇

@kongruxi 要作为模块编译到nginx，看过篇文章性能是文件的1/6。所以没到海量文件的时候还是用文件吧。

Google+ 疲软期间 Twitter 时髦度节节上升