数据库触发器与Rails ActiveRecord回调的优缺点?

时间:2011-09-08 08:57:09

标签: ruby-on-rails activerecord triggers materialized-views

我正在使用Ruby on Rails和PostgreSQL编写程序。系统生成很多报告,这些报告经常被用户更新和频繁访问。我是否应该使用Postgres触发器创建报表表(如Oracle物化视图)或内置ActiveRecord回调的Rails。有没有人对此有任何想法或经验?

2 个答案:

答案 0 :(得分:15)

回调在以下情况下很有用:

  • 结合Rails模型中的所有业务逻辑,以简化可维护性。
  • 利用现有的Rails模型代码
  • 易于调试
  • Ruby代码比sql“可维护性”
  • 更容易编写/读取

触发器在以下情况下很有用:

  • 表现是一个很大的问题。它比回调更快。

如果您的关注是轻松和干净,那么使用回调。如果您关注的是性能,那么请使用触发器。

答案 1 :(得分:7)

我们遇到了同样的问题,因为这是一个有趣的话题,我将根据我们的选择/经验进行详细说明。

我认为这个概念比当前答案中强调的要复杂得多。

由于我们正在谈论报告,我认为用例是更新数据仓库表 - 而不是"泛型"申请(这种假设/区别至关重要)。

首先,"易于调试"这个想法不一定是真的。在我们的例子中,这样做实际上会适得其反。

在足够复杂的应用程序中,某些类型的回调(数据仓库更新/数百万行代码/中型(或更多)大小的团队)根本无法维护,因为数据库的更新位置和方式太多了,调试错过的回调几乎是不可能的。

触发器不一定必须设计为复杂且快速的"逻辑。 具体来说,触发器也可以作为低级回调逻辑,因此简单而精简:它们只是将更新事件转发回rails代码。

总结一下,在上面提到的用例中,应该像瘟疫那样避免使用rails回调。

高效且有效的设计是让RDBMS触发器将记录添加到队列表,以及作用于它们的rails-side排队系统。

(由于这篇文章很老,我很好奇OP的经历是哪一次)