Storm 实在是太强大了

[Livid]

或许这不是一段很好的代码，但是刚才实在是被模版里这样的一段表达式给震撼了：

{{ mention.event.reply_to.member.username }}

[Los]

rails 里最不缺少的就是这个

[ayanamist]

已经看到无数人吐槽Storm后转到SQLAlchemy了，期待过一段时间后Livid的吐槽。

[Livid]

@ayanamist 吐槽点是？

[huangz]

数据量大之后Storm会出现莫名其妙的锁表问题，在pythoncn的邮件列表里有个帖子说到过。

[muxi]

@huangz 所有的ORM在数据量大了之后都是鸡肋，而且没法优化或者很难优化

[chloerei]

@muxi @huangz 不要过早优化

[chloerei]

补充一下，实际中做页面片段缓存或者对象缓存或者队列缓存，比数据库层面的优化更好。

[est]

编程语言设计有两个方向，一钟是接近数理逻辑，一种是接近人性化。

[huangz]

@muxi @chloerei

是的，受教了。

我是看到有人问，才指出 Storm 存在的问题而已。实际上，比起 SQLAlchemy 我更喜欢简单易用的 Storm 多一些。

[ayanamist]

@muxi 问题是同等数据量的情况下Storm问题多多，但SQLAlchemy却没问题
http://blog.chinaunix.net/space.php?uid=20507440&do=blog&id=1939574
https://ddbean.wordpress.com/2010/07/01/pylons-%E5%85%A5%E9%97%A8%E5%AE%9E%E4%BE%8B%E6%95%99%E7%A8%8B-%E2%80%93-%E6%95%B0%E6%8D%AE%E5%BA%93%E6%93%8D%E4%BD%9C/

[Livid]

@ayanamist 感谢分享。

不过 March Liu 的情况是：

• 他用的数据库是 PostgreSQL
• 他用到了 foreign key

而目前我的项目里是 MySQL，而且没有用到 foreign key，也暂时还没有用到 transaction，所以目前一切情况还好。

当然，如果将来在我的项目中的 Storm 出现了什么奇怪问题，我会在第一时间在这里向大家分享和请教细节的。

[ayanamist]

@Livid 反正从我看他们的代码而言，SQLAlchemy的代码质量比Storm要好太多了。

[muxi]

@chloerei 去年的今天我也是这么想的，先做起来再说。互联网业务速度增长的非常的快，就那么几个人，业务不断的还在继续增长，需求不断的新增，新招聘的人不能马上介入开发，这都是问题，虽然我不后悔当初对ORM的选择，但是从发展层面来说，我遇到了ORM这个模式本身的问题，从技术层面去重构程序需要面临的压力非常的大，首先你得保证现有业务的稳定性，还得保证能持续优化，在重构没有完成之前不能拖业务的后退，还得面临新需求的开发和迭代。在一个业务驱动的团队里，在系统没有倒掉之前，基本上你的领导都会告诉你，先做xxx，然后再去优化，等到真正倒掉的时候，开始心急火燎的要你xx天完成重构工作，而且还得保证新需求的研发。

So，我的建议是，考虑你未来18个月的需求，这不是过度优化，而是前瞻性眼光。如果你不能预估，那么就按照100倍来估计，如果你项目刚刚还是上线，还没有流量，至少要保证能承受每秒1000个请求，哪怕是现在不能，但是未来可以通过添加服务器横向扩展达到。在12个月后，重新检查你的系统，如果不能满足从那以后18个月的需求，你应该着手布置你的重构计划，如果你不能，那么至少也要邮件说明。

[keakon]

都不知道这些ORM怎么处理异步，于是觉得还是自己发明轮子算了

[fanzeyi]

曾经被 March Liu 批了一顿之后被推荐去用 SQLAlchemy 了..

[Livid]

@keakon 我打算改天试试 Tornado 里新增的 gen 能否用来搞定数据库写入的异步。

[fire5]

SQLObject