RubyonRailsとPostgreSQLを使ってプログラムを書いています。システムは、頻繁に更新され、ユーザーが頻繁にアクセスする多くのレポートを生成します。Postgresトリガーを使用してレポートテーブル（Oracleマテリアライズドビューなど）を作成する必要があるのか、ActiveRecordコールバックに組み込まれているRailsを使用する必要があるのかがわかりません。誰かがこれについて何か考えや経験を持っていますか？
4860 次
2 に答える
17
コールバックは、次の場合に役立ちます。
- すべてのビジネス ロジックを Rails モデルに統合し、保守を容易にします。
- 既存の Rails モデル コードを利用する
- デバッグが容易
- RubyコードはSQLよりも書きやすく読みやすい「保守性」
トリガーは、次の場合に役立ちます。
- パフォーマンスは大きな懸念事項です。コールバックよりも高速です。
懸念事項が簡単でクリーンな場合は、コールバックを使用してください。パフォーマンスが懸念される場合は、トリガーを使用してください。
于 2011-09-08T09:55:26.020 に答える
9
私たちも同じ問題を抱えていました。これは興味深いトピックなので、私たちの選択/経験に基づいて詳しく説明します.
この概念は、現在の回答で強調されているものよりも複雑だと思います。
レポートについて話しているので、ユース ケースはデータ ウェアハウジング テーブルの更新であり、「一般的な」アプリケーションではないと仮定します (この仮定/区別は重要です)。
まず、「デバッグしやすい」という考えは [必ずしも] 正しくありません。私たちの場合、そう考えるのは逆効果です。
十分に複雑なアプリケーションでは、いくつかのタイプのコールバック (データ ウェアハウジングの更新/数百万行のコード/中規模 (またはそれ以上) の規模のチーム) を維持することは単純に不可能です。失敗したコールバックをデバッグすることは事実上不可能です。
トリガーは、必ずしも「複雑で高速な」ロジックとして設計する必要はありません。具体的には、トリガーは低レベルのコールバック ロジックとしても機能する可能性があるため、シンプルで無駄がありません。単に更新イベントを Rails コードに転送するだけです。
まとめると、言及されたユースケースでは、レールコールバックは疫病のように避けるべきです。
効率的かつ効果的な設計は、キュー テーブルにレコードを追加する RDBMS トリガーと、それらに作用するレール側のキューイング システムを使用することです。
（この投稿は古いので、OPの経験はどれだったのか気になります）
于 2016-01-15T10:31:58.537 に答える