1、是否有众多，稳定的 plugins（扩展），像 PHP 的 lib 那样。

其实每个 Web 框架都会认为自己是这样的。所以，具体问题还得具体分析。

2、是否适合一个快速开发，很明显 CSS, HTML 一个人多。

同上

3、生产环境下运行是否稳定。不要内存溢出等。

同上。内存占用这个问题。一个 PHP 进程，如果不是太复杂的应用，不抛错，基本都能一直保持在 10M 以下。而 Django 非常非常能吃内存，一个 Django 进程的内存占用基本上就不用妄想能小于 10M 了。

这个链接里比较的有点老，和现在的情况可能有点区别了。那时候 Rails 3 应该才刚出来，所以里面才是 2。

http://nuald.blogspot.com/2011/08/web-application-framework-comparison-by.html

当然多吃几倍内存其实没啥。碰到 Bug，才叫人欲哭无泪呢。碰到过某程序，每次把数据存进数据库的时候会 escape 一下，但取出来不会 unescape，接着它又不停地取出来写回去。好了，这条记录这个字段的大小就开始指数增长了，很快，别的读到这条记录的进程都因为这个被 OOM 了。

我的项目是一个功能简单的社交网站，但是用户级别在 200W 左右。

什么功能，简单到何种程度？用户级别的定义是啥？总注册用户数？平均日活跃用户？峰值同时在线用户？将在什么时候达到 200W，即将达到，还是不知道什么时候会达到。

我不注重性能，为什么？ 那种 hello word 的测试简直弱爆。把 view 解析，DB 连接 加上后其实大家都差不多。

我不知道你怎么得出这个结论的

关键是看开发效率、难易程度。生产环境稳定与否。

同第一条。开发效率、难易程度。生产环境稳定与否，到底哪个更重要？

请问。RAILS3 适合我吗。

假如你自认为新手，我觉得 Rails 就不适合你。

我之前用过 Django，觉得 Template 太要命了。都是一个开发人员做，没专职 designer。

Django 的 Template 早就可以随便换了，只是从来不强调罢了

https://docs.djangoproject.com/en/1.4/ref/templates/api/#using-an-alternative-template-language

我认为对于 Full-Stack 的框架来说，能换成更好的是次佳选择，集成最好的作为默认的才是应该的。在这点上，Django 和 Rails 简直就是一对活宝啊。

Django 官方当年非常脑残地认为，默认模板语言一定要故意和 Python 不一样才算是适合设计师使用的，非要认为这才符合他们的哲学。后来终于在大家的鄙视下，终于允许{% if x == y %}了，现在也不提啥 Django 的哲学了。当然这也导致了，现在 Django 的模板其实不是最佳选择。

#9 楼 @cxh116 就第一次需要改 nginx 配置吧，那就直接 root 去改了

因为没有人擅长评估开发时间

第二个

Jikes RVM (Jikes Research Virtual Machine) is a mature open source virtual machine that runs Java programs.

#17 楼 @fsword 我都说了用INSERT OR IGNORE之类的办法了，不需要自己判断，直接丢给数据库就好。

我会告诉你我用 Django Admin+QBE 么

http://versae.github.com/qbe/

#12 楼 @fsword 不是啊，无论多少数据量，你最终数据库写入的数据量是一样的，就是 4000 个手机号码。而现在 LZ 的问题是，SQL 语句数是O(n)的，而实际上是可以做到O(1)的。

#8 楼 @fsword 目前最大的问题是能用一句 SQL 搞定的他用了 4000 句

#6 楼 @huacnlee 加索引会减慢写入速度，按 LZ 这个写法，加不加索引，关系不大。

#4 楼 @chucai 你就再用一个SELECT么

#2 楼 @chucai 用 SQL 生成随机数应该可以的。

用 SQLITE 可以用INSERT OR IGNORE一次插入很多条记录，问题是 SQLITE 一条语句参数个数是有上限的，一次插入 4000 可能已经超了。别的数据库应该也有类似的方法，且没参数个数的限制。

这两个可以一起用的吧

文档里不是告诉你，看 RFC 4122 了么

http://tools.ietf.org/html/rfc4122#section-4.4

理论上就是不保证唯一的

#41 楼 @zw963 C++ 里就很有关系啊，不会 TemplateMetaProgramming 别说你会 C++

#18 楼 @Saito 为啥，akka 有高科技？scala 消息的实现挺快的啊，不比 Erlang 慢啊，问题是发的消息里面有需要被 GC 的就不行了。

或者把机制改一下，服务端返回镜像列表，客户端自己选一个。

MFC 比 Delphi 恶心多了。搞了一大堆宏，就为了实现 Object Pascal 里 dynamic 关键字一样的效果。离开了 IDE，完全就没法开发了。

#16 楼 @fsword 分布式怎么样我不知道，反正单机情况下，Java 系的 Actor Model 都被 GC 拖死了。而那个 disruptor 的实现，更接近于我先占一大片内存下来，我自己管理内存...

https://code.google.com/p/disruptor/

我也觉得直接丢给数据库比较好，但问题很可能是数据库只会报个 IntegrityError，你不知道是哪 (几) 个 Field 重复导致的。我觉得即便如此也应该先 INSERT，失败再去查询。

#9 楼 @fsword 线程和协程只是并行。为了并发，Java 系的往往需要消息中间件或者之类的东西

#31 楼 @fleuria 我知道问题在哪里了。我之前一直在强调的是有了 South，Django 也可以像 Rails 那样做 migration 了，schema migration 也是可以和 data migration 放在一起的。我认为剩下的部分是很显然的就没说了。

那从头来过：

首先是 migration 本身

• migration 是因为 RDBMS 有 schema 才出现的需求
• 有时候 schema migration，也会附带需要转换数据，所以 migration 需要支持 data migration
• 恰好，临时的数据转换，也可以通过这个机制来做

接着 Django+South

• Django 本身没有 migration 的功能。South 为 Django 提供了必要的 migration 功能
• 按照 Django 的风格，和 schema 变化有关的 migration 应该放在 app 里，临时的 data migration 放在 project 里，这样就避免了坏味道。

之前的分歧就在于，

我说的是，和 schema 变化有关的 data migration 是可以 schema migration 放在一起。 你想要的是，和schema变化有关的migration，临时的data migration，这两个应该放在不同的地方。

这样应该没问题了吧。上面的确是有一些回得太快了，没注意上下文的。漏的引用啥的，我都补了下。

bisect?

#29 楼 @fleuria

你说的大家都懂，可是楼主说的什么你真的确定看明白了么。 不学下 rails，不让实际的项目多虐几下，凭自己在 django 里面了解的经验就能理解了别人在说什么？

migration 的需求来自哪里？来自 RDBMS。因为你有了 schema，你才要 migrate。只要会用 SQL 的，都能理解这个问题。无论你用 CGI 还是 ASP 还是 PHP 问题都是一样的，和框架有关的只是框架对这类需求提供何种程度的支持。而临时转换数据只是恰好能通过这种机制来处理罢了。

太轻巧了。世界真这么美好就好了。不用学我就比你们还懂 rails，不用学我就比你们更清楚 rails 的弱点在哪儿，不用学我就能指点你们该怎样解决现实问题。

我从头到尾说的都是 Django+South 刚好没这个问题，从头到尾都没说过如何在 Rails 里解决这问题吧。不知道你是怎么看出来的。

哪怕花上半个星期草草过上一遍 rails guide，也不至于说这些天真的话出来。

你是怎么得出我没看过 Rails Guide 的结论的。如果你指的是 Rails 3.x，那我的确没有。但我有必要告诉你我看过 Rails 2.x 的 Guide，看过 3.0/3.1/3.2 的 ChangeLog 么？我有必要告诉你我折腾过几个 Rails 项目么？这些都是 BS，说出来一点信息量都没有，不是么？

#24 楼 @fleuria 有关啊。South 能做 migration，South 的风格刚好和 LZ 想要的一致。而按 Django 本身的约定，天然就把临时的和与代码相关的 migration 分在 project 和 app 里了。这问题自然就结了。

#26 楼 @hooopo 我觉得这是 ActiveRecord 视角的问题。从 ActiveRecord 的角度看，schema 是根据 migration 文件的操作结果计算出来的。而从 DataMapper 的视角看，migration 文件是根据 schema 的变化生成出来的。因为你开发的时候并不需要准备好的 migration 文件，schema migration 和 data migration 放在一起并不是什么问题，但也不希望这么干的。

Update:
上面是说开发的branch里可以完全不放migration代码。这样哪怕migration烂掉也无所谓。但从洁癖出发，还是别烂掉好。所以才有下面。

在 Django 里，按照 Django 的代码组织风格，是分 project 和 app 的。一般不在 project 里定义 model。app 发布的时候要带上 migration 文件，处理 schema migration。而临时性的 data migration 就放在 project 下了。因为每个 app 的自增数列是独立的，所以就没问题了。

myproject/
    migrations/    <- 临时的
        0001_data_...
        0002_data_...
        ...
myapp1/
    migrations/
        0001_schema_...
        0002_schema_...
        ...
myapp2/
    migrations/
        0001_schema_...
        0002_schema_...
        ...
...

按 Rails 的说法，就是项目？里不准定义 model，全在 Engine 里定义，每个 Engine 的 migration 的自增数列是独立的，临时性的 data migration 统一在项目里做。

#22 楼 @hooopo 你这个放在一起指什么？

South 就只认，migration 文件里的Migration的forward和backward两个函数，在这两个函数里，你既可以做 data migration 也可以做 schema migration。

当然了，实际上，两个命令会生成不同的模板，一个class Migration(DataMigration)，一个class Migration(SchemaMigration)。

这个是补上面的，囧...

#20 楼 @fleuria South 并不严格区分 schema migration 和 data migration，对于 data migration，South 生成一个模板，你自己往里填内容。其实，schema migration 你也可以用datamigration生成模板，并在那个基础上改改的。无非schemamigration那个命令，会自动检查 model 的变化，尽可能帮你自动生成而已。

South 就只认，migration 文件里的Migration的forward和backward两个函数，在这两个函数里，你既可以做 data migration 也可以做 schema migration。

当然了，实际上，两个命令会生成不同的模板，一个class Migration(DataMigration)，一个class Migration(SchemaMigration)。

#18 楼 @fleuria

1.没有统一的约定去组织这些文件

South 规定了 migration 文件怎么写，放哪里

2.没有 generater 去生成

只要有可能，South 会尽量为你生成更多东西

3.需要人为记录文件是否执行过

记录在数据库里

4.没有顺序

South 规定要有顺序

#14 楼 @hooopo

不过这东西用递增序列做版本号不怕多人开发的时候冲突么？

开发的时候你在 models.py 里定义 Model。只是在最后部署的时候，让 South 生成一下 migration 文件。