私はRuby on RailsとPostgreSQLを使ってプログラムを書いています。システムは頻繁に更新され、頻繁にユーザによってアクセスされる多くのレポートを生成する。私は、Postgresのトリガを使ってOracleのマテリアライズド・ビューなどのレポート・テーブルを作成するか、ActiveRecordコールバックでビルドされたRailsを作成する必要があるかどうかを掘り下げています。誰にもこれに関する考えや経験がありますか？データベースのトリガーの長所と短所対Rails ActiveRecordのコールバック？
コールバックは、次のような場合に有用である：
のトリガーは、次の場合に有用である：
気になる場合は、コールバックを使用してください。あなたの懸念がパフォーマンスの場合は、トリガーを使用してください。
私たちは同じ問題を抱えていました。これは興味深い話題なので、私たちの選択/経験に基づいて詳しく説明します。
コンセプトは、現在の回答で強調表示されているものよりも複雑だと思います。
私たちはレポートについて話しているので、使用例は「汎用」アプリケーションではなく、データウェアハウステーブルの更新であると仮定します（この仮定と区別が重要です）。
まず、「デバッグしやすい」アイデアは必ずしも真実ではありません。私たちの場合、実際にそう考えることは逆効果的です。
十分に複雑なアプリケーションでは、データベースの場所や方法が非常に多いため、いくつかのタイプのコールバック（データウェアハウスの更新/数百万行のコード/ミッド（またはそれ以上）のチーム）は維持するのが単純ではありません。更新されていないため、欠落したコールバックをデバッグすることは事実上不可能です。
トリガは、必ずしも "複雑で高速な"ロジックとして設計する必要はありません。 特に、トリガは低レベルのコールバックロジックとしても機能するため、単純でリーンなので、単に更新イベントをレールコードに転送するだけです。
上記の使用例では、折り返しを行うために、レールのコールバックはペストのように避けるべきです。
効率的かつ効果的な設計では、RDBMSトリガーにレコードをキュー表に追加し、レール側キューイング・システムを使用してそれらを処理します。
（この記事は古いですので、私はOPの経験となっていた好奇心よ）
トリガーを使用すると、パフォーマンスの増加の理由は何ですか？ – Zubair
コールバックではDBに接続するので、トリガーではdbに接続する必要はありません。すでにdbレイヤーにあります –
ああ意味します。ありがとう – Zubair