我有机会与迄今为止使用Ruby on Rails的人交谈，然后在达到限制时不得不放弃它，或者发现它最终过于僵化。我忘记了细节，但可能与使用多个数据库有关。
所以我想要知道的是Ruby on Rails之外的功能/要求是什么，或者至少需要这样的扭曲，即使你可能不得不失去一些优雅，更好地使用另一个更灵活的框架或编写额外的样板代码。
答案 0 :(得分：12)
Rails（不是ruby本身）很自豪能成为“Opinionated Software”。
这在实践中意味着rails的作者有一定的目标受众（他们自己基本上）并且专门针对那些目标。如果目标受众不需要X功能，则不会添加。
在我的头脑中，显然不支持人们可能关心的事情：
也就是说，使用插件扩展rails是非常容易的，并且有一些插件可以将所有上述功能添加到rails中，还有更多，所以我不会将它们视为限制。
唯一的另一个警告是围绕使用MVC创建CRUD Web应用程序的想法构建了 。如果你正在尝试做一些不是CRUD网络应用程序的东西（比如twitter，它实际上是一个消息传递系统，或者你是疯了，想要使用像ASP.NET网页这样的模型）那么你也会遇到问题。在这种情况下，你最好不要使用铁轨，因为你基本上是想用自行车零件建造一艘船。
很可能，你遇到的问题不能只用快速插件或一天或两天的编码修复，这些都是底层C Ruby运行时的固有问题（内存泄漏，绿色线程，废话性能）等等。）
答案 1 :(得分：5)
Ruby on Rails不支持开箱即用的两阶段提交，如果您的数据库支持的应用程序需要保证即时一致性并且您需要使用两个或更多数据库模式，则可能需要这样做。
对于许多Web应用程序，我冒昧地认为这不是一个常见的用例。人们可以很好地支持与两个或更多数据库的最终一致性。或者可以支持与一个数据库模式的立即一致性。如果您的应用程序必须支持mondo数量的交易，那么前一种情况是一个很大的问题（请注意技术术语:)。后一种情况更典型，Rails也没问题。
坦率地说，在您遇到真正的可伸缩性问题之前，我不会担心使用Ruby on Rails（或任何框架）的限制。首先构建杀手应用 ，然后担心可扩展性。
澄清：我正在考虑Rails会有一个难以支持的事情，因为它可能需要在其架构上进行根本转变。我会慷慨并包含一些属于gem / plugin生态系统的东西，例如外键实施或SOAP服务。
通过两阶段提交，我的意思是尝试在一个事务上下文中对物理上不同的服务器进行两次提交。
用例＃1用于两阶段提交：您已对数据库进行了群集，因此您有两个或更多数据库服务器，并且您的架构分布在两个服务器上。您可能希望提交两个服务器，因为您希望允许ActiveRecord认为执行遍历不同服务器的“外键映射”。
用例＃2进行两阶段提交：您正在尝试实现消息传递解决方案（抱歉，我是白天的J2EE开发人员）。消息生成器提交消息传递代理（一个服务器）和数据库（另一个服务器）。
答案 2 :(得分：1)
还找到了关于limits of ActiveRecord的一些很好的讨论。
答案 3 :(得分：1)
我认为这里有一个更大的“元问题”，可以回答，“什么时候可以依靠外部库来加快开发时间？”
第三方图书馆往往很棒并且可以大大减少开发时间，但是有一个主要问题，Joel Spolsky称之为“泄漏抽象法则。”如果你在谷歌看来，他的帖子将首先出现。从本质上讲，这意味着开发时间的权衡意味着您不知道幕后发生了什么。所以当出现问题时，你会完全陷入困境并且调试方法非常有限。这也意味着，如果您遇到RAILS中根本不支持的功能之一，那么您真正需要的是，如果您很幸运，除了自己编写功能外，您将没有下一步。许多图书馆都难以做到这一点。
我们的开发商店已经被这个问题严重烧伤了。我们的解决方案在正常负载下运行良好，但我们发现我们使用的第三方订阅库无法承受我们的网站开始获得大量并发用户后所遇到的负载。这使我们处于一个非常困难的地方;基本上我们必须自己重写整个订阅服务，并考虑到性能。这样做意味着我们一直浪费在使用库上。
第三方库对于中小型应用程序非常有用;它们可以大大缩短开发时间，并隐藏在开发早期阶段无需处理的复杂性。然而，最终他们会赶上你，你可能不得不重写或重新设计你的解决方案，以超越“泄漏法则”
答案 4 :(得分：1)
Ruby在ASP.Net中没有像IsPostBack这样的功能
答案 5 :(得分：0)
猎户座的答案是正确的。 AR / Rails几乎没有硬性限制：部署到Windows，不经常使用的AR连接器，例如： Firebird，），但即使是他提到的东西，多个数据库和数据库服务器，还有一些宝石和插件可以解决遗留，分片和其他原因。
真正的限制是保持rails devs正在处理的所有事情，研究具体问题，考虑到有多少博客以及有多少邮件列表量，这是多么耗时。