为什么用RoR?为什么不用RoR?

呵呵，我也想“用Ruby（甚至Rails）处理复杂的数据库”，不过从目前的情况来看，分库的策略没有固定模式，所以就算是用Rails也会有大量配置，这和Rails的约定大于配置刚好相反，这也是Rails不适用的一个主要原因，Rails甚至不能很好地处理遗留数据库。这种情况下，抛开Rails可能是最佳选择，或者是只抛开ActiveRecord，把中间层的接口用Ruby封闭也是挺简单的事，还是可以尝试的，如果有这方面的应用我自然也是可以分享一下经验，不过目前还没有。我也没有这个能力把这种复杂数据库和ActiveRecord给联系起来，中间的差异还是太大。

说到解决方案，实际上已经说得比较清楚了，就是分库分表加上中间层，前台只写简单的页面逻辑，业务架构由中间层处理，目前国内排前20的网站大概都是这种模式，再细还能说什么？

恩，其实 qiezi 已经给出了答案，
就是那种情况下，rails 不是特别合适的。

如果一定要用 rails 的方式并且给出开源社区一个答案，那还得
等qiezi 有了新的答案的再说吧！

那你们现在用的什么?
又回到PHP了？

这个问题在我看来同业务层采用什么框架，没有多大关系。
主要应该属于数据存储优化问题，虽然我们做的证券交易系统数据量没有你们公司网站的大，但却也仔细地考虑过数据分库的问题。
有两种较好的方法：
1.提供一个历史库，结构几乎同当前库相同。这对于当天交易查询敏感的系统来说相当重要。实际上，银行也是这么干的，所以在网上银行会看到当天交易查询和历史交易查询两个功能。
2.某些表分库。你上面的做法既有不同的用户放到了不同的库中，也有同一用户的信息放到了不同的库中。基于耦合和封装的考虑，我认为只需要前者就可以了，后者会带来很大的副作用。把一个用户及其关联的所有附属信息，放到同一个数据库中。这样所有数据库的结构是完全相同的，只需要通过用户的标识就可以确定到那个数据库完成给定的操作，操作完全和操作一个数据库相同，这样就可以单点控制这个问题，并且可以平滑的从单数据库过渡到多数据库。但是如果把一个用户的信息分散到不同的库中，那么，分散控制就不可避免。并且，如果要取到用户的关联信息，数据库透明处理完全不可能。

另外一个次要问题可能是通信，一种比较笨的方法，就是扩大应用服务器的数量。

事情都是这样的，谁能一开始想那么远呢？先拣手头的合适的工具上手再说，以后再慢慢改慢慢优化。即使到最后把以前的都推翻了也是核算的。

顺便说，如果富客户越来越流行，以后连eruby/jsp/php这些动态页面显示层大概也没用了，就只剩中间件+静态页面+富客户。。。

我也是这么想的，富客户+中间件，静态页面都没必要了，呵呵。

那这种中间件，用Rails是再合适没有了，Rails已经提供了完善的REST和XML输出支持，什么Flex啊，Ext-js啊，都合作良好，你唯一要做的，就是把ActiveRecord改成ActiveCICS或者ActiveTuxteo或者ActiveSocket...

这也是合理的。目前我们用C++写中间件，都是自定义协议格式。如果直接提供给客户端，协议上还得包装成XML或其它，一些安全方面的逻辑还是要有一层，因为这些C++中间件基本上都是内网使用，不考虑安全性，也没办法考虑，它的功能相当于自己实现高性能cache的数据库，每一个调用相当于一个存储过程。

单机最大负荷也要考虑，这牵扯到server的数量（硬件、部署、维护都是钱啊）。
貌似ruby性能不是很好：无法使用多cpu，NIO机制不知道有没有，这必然导致单机负荷巨降，做中间件估计不合适。

通常银行系统对于稳定性、逻辑原子性的要求比较高，性能要求相对较低，我在网银上转帐通常一次操作要十几秒，但在网站系统上这是不可接受的。网站通常对于性能和稳定性要求比较同，操作原子性都排到后面了，有时候甚至是异步写，比如用户发个帖子加5分，我只要保证他马上能看到帖子，马上能刷新他cache里的分数，什么时候加到数据库里面作永久存档都不重要。这种需求的差异带来的数据库设计差异也是比较大的。

你的第一个方法，对于一个用户多条记录的，比如论坛发帖是可以的，不过通常论坛是按最后回复来排序，分开是否不合适？这种方式对于支付系统还是可以考虑的。

第二个方法，我前面简单描述过，通常不能把一个用户所有信息放在一起，因为有时候某些表负载会比较高，不希望一些不重要的系统影响到登录、积分这些严重影响用户体验的。全部放在一起，可能就会分出更多的相同结构的数据库服务器，维护也是比较麻烦的。另外有些相互关联的比如某用户的好友，某用户是谁的好友这2个反向关系，其它一些我发出的邮件和我收到的邮件，每添加一条记录都是要写2个不同表的。

公司有产品部门，他们会分析哪些东西对用户是最敏感的，页面元素甚至一个小链接一个小图标对用户的影响，所有的系统架构基本上都要考虑他们的分析结果，通常他们的意见都是和用户非常贴近的。