以下是我对每种方法的看法：
不，不应该。有些计算在数据库中运行要快得多，有些则不然。然而，准确地测试哪些计算应该在数据库中运行将是困难和耗时的，并且您将正确地体验到算法的某些部分在postgresql或您使用的任何东西中是缓慢的。更重要的是：这不是运行逻辑的正确位置，正如你自己所说的，这将很难测试，而且总体来说这是一个糟糕的实践。每次数据库必须计算算法时，它也会影响请求的整体性能。另外，数据库仍然会使用大量的内存来处理这个问题，所以这不是一个优势。
到目前为止最好的解决方案。请参阅下面的详细说明。
这是一个比第一个更好的解决方案。然而，这将意味着你的应用程序性能将非常不稳定。有时所有的资源对于正常的请求都是免费的，有时你会把所有的资源都用在你的计算上。
选项2是最好的解决方案，因为这不会影响应用程序其余部分的性能，而且由于它是独立工作的，因此更容易扩展。例如，如果您的工作人员无法跟上，您可以添加一些正在运行的进程。
更重要的是，您将能够在单独的服务器上运行后台进程，从而轻松地监视内存和资源使用情况，并根据需要扩展服务器。
即使对于实时更新，后台工作也是最好的解决方案（当然，如果计算量不足以在请求中完成的话）。您可以创建一个“高优先级”队列，该队列具有足够的资源，几乎总是空的。如果需要通过重新加载向用户显示结果，则必须在后台作业完成后添加某种推送通知。然后，这个通知可以通过javascript触发页面的更新（您还可以查看rails4的新的live stream函数）。
我会推荐一些类似redis的sidekiq。然后可以将结果缓存在memcache中，或者每次都可以重新计算结果，这实际上取决于计算的频率。然而，有了这个解决方案，如果您需要的话，设置一个稳定的缓存会容易得多。
在我工作的地方，我们有一个应用程序，它运行一些繁重的查询，有很多这样的计算。每天晚上，这些作业都会排队，然后在接下来的几个小时内在一个独立的服务器上运行。这是非常好的规模，也很容易监测与新的文物。
希望这有帮助，有意义（我知道我的英语不是很好），但是如果我误解了什么或者你有更多的问题，请随时问。