#12 楼 @qhwa 现在去淘宝明显不划算....

-1

好歹加个注释吧

#7 楼 @huacnlee recursive cte 才是正解来着，disqus 都用了好几年了，应该不存在明显性能问题。MPTT 浪费存储空间还只能有一种排序方式，坑爹着呢...支持多种排序就可以自己选排序方式，比强制顺序或者树形略不坑爹一点

http://justcramer.com/2010/05/30/scaling-threaded-comments-on-django-at-disqus/

#56 楼 @kgen 为了用户体验，Mac 去掉了默认支持中键复制？

这是个还没解决的问题

Fedora 18 上的 TeXLive 才勉强能自动把 TeXLive 里的包变成 yum 仓库里的包，这估计还是目前已知的系统包管理和语言包管理整合的最好的那个... https://fedoraproject.org/wiki/Features/TeXLive

看你要开发啥...

这完全是两种风格啊。Ruby 那 require 就好像 C 语言的#include，Python 的 import 分明是文件系统的符号链接

为什么要学 Ruby ...

#30 楼 @Rei

1. 不是只有select *才能把所有字段取出来。
2. 这里就是少取一个字段即可避免拆表

#27 楼 @Rei

首先是一句废话，用什么数据库取决于你的应用类型。

为什么要用 RDBMS，是因为数据本身之间存在关系啊。数据关系处理起来是很难的。要应用自己保证 ForeignKey Constraint 还是太麻烦了，所以才会出现各种 RDBMS。这也是为什么你总是要先 normalize 找出所有关系。

数据量上去之后，关系数据库的 join 查询都不能用

不是的。假如你知道你需要哪些 JOIN。Oracle 的 Table Cluster 可以把相关数据放在一起，这样即便是一个很大的 cluster，也是可以 JOIN 的。Google 开发的 F1 也是这么干的。

我更加坚定用 Mongodb 了

MongoDB 解决的完全不是同一类问题。你用 MongoDB，你对数据的假设是，对于任意一条记录，任何地点都可能对它发起写请求，且不存在某个地点发起写请求的次数特别多，此时你想要保证多数地点要可写。对，默认你已经跨地理分布的多个数据中心了。

#26 楼 @Rei 我不是说不该为了性能原因拆表什么的。把拆表这个问题无限制扩大范围是得不出什么结论的，最多就是根据应用类型来决定，那就是一句废话。

我是说 robbin 这个例子拆跟不拆没什么区别，可能还是不拆好....这里根本就没给出任何理由。整篇下来基本就这么个思路。现在采用的这种方式比最烂的好很多了，所以这是一种很好的方式。

#24 楼 @Rei 不要扯开去啊，就这个例子，把 blog contents 拆表，这拆跟没拆有什么区别么...

#21 楼 @huacnlee 不拆表，1+1 也可以达到相同效果。完全不能苟同这种说法

#18 楼 @hooopo SELECT *是公认的 bad practise。只要你没理由，是不该用SELECT *的。SELECT *首先是让代码维护变得困难，其次是有性能损失。

难道在这里SELECT *一点问题都没有吗？就是你用了该死的SELECT *你才要拆表。

#16 楼 @hooopo

1. 反正你的理由不够有说服力。且此处不用SELECT *显然不用拆表...

2. 有能支持 N+1 不能证明没有能支持 1+1 的啊

好吧，我还是来恶心他一句，从 2007 年到 2013 年，一点点长进都没有啊，我都不想为他捉急了

#13 楼 @jasl 基本上每个点都有值得怀疑的地方。就算大体按他这个思路，我们现在来看一下 n+1 那个点。

明明是可以 1+1 的，也不用拆成两张表的。所有 ID 都已知啊，直接一条 SELECT 不就完事了。1 条和 n 条对数据库没有本质区别。且 n 条多浪费 n-1 次 round trip。

一边说要省 I/O，拆表增加了 I/O 负担就不提了。特别是他这个例子里，拆跟没拆没啥区别的。

其实嘛，大谈数据库，还是要抠那么点性能的，连SELECT *出现都不给理由的，这篇文章肯定是没用心写。吐槽真的很无力。

#8 楼 @zw963

我觉得现在硬件运算能力过剩，当玩具用很不划算啊，还不如来一打低端硬件。连开虚拟机的事都省了，直接换一块板就是了...

能有个几打这种级别的硬件我就满足了...

http://linux-sunxi.org/Cubieboard

吐槽无力，完全无力苟同 n+1 有利于缓存的观点。

#13 楼 @fredwu

对于 Python 的 decorator 有什么看法—— Ruby 今后会增加 decorator 吗？

突然想起来，特来挖坟

从语法上讲实现这个功能毫无压力。但是从语义上讲，Ruby 有函数这个概念吗，有吗？没有吗？反正怎么说都说不清楚，哈哈哈哈哈哈哈......

#1 楼 @zw963 你送我一台那就可以考虑...

#19 楼 @mobiwolf 我觉得你还是别简单地说和微信类似。还是把功能点一个个列下来，不走 XMPP 的不管。需要走 XMPP 的，对照 Ejabberd 支持的协议http://www.process-one.net/en/ejabberd/protocols/，把没有支持的拿上来讨论吧。

Erlang 真的是一门很容易上手的语言...

#2 楼 @lidashuang

http://redmine.lighttpd.net/projects/1/wiki/Docs_ModFastCGI#X-Sendfile

http://wiki.nginx.org/X-accel

rietveld/gerrit被赤裸裸地忽略了

X-Sendfile???

#9 楼 @luikore 传言说学会法语自然就精通乘法表了来着...