データベースからのオブザーバーパターンの実装は、通常は避ける必要があります。
なんで？ベンダー独自の（非標準の）テクノロジーに依存し、データベースベンダーのロックインとサポートのリスクを促進し、多少の肥大化を引き起こします。エンタープライズの観点からは、制御された方法で実行されない場合、「スカンクワーク」のように見える可能性があります。これは、アプリケーションと統合のパターンおよびツールで一般的にカバーされる動作を通常とは異なる方法で実装します。きめ細かいレベルで実装すると、予測できない大量の通信と処理を伴う小さなデータ変更との緊密な結合が発生し、パフォーマンスに影響を与える可能性があります。マシンの余分な歯車は、余分なブレークポイントになる可能性があります。O/ S、ネットワーク、セキュリティ構成に敏感であるか、ベンダーテクノロジーにセキュリティの脆弱性がある可能性があります。
アプリによって管理されているトランザクションデータを監視している場合：
- アプリにオブザーバーパターンを実装します。例えば。 Javaでは、CDIとjavabeansの仕様がこれを直接サポートしており、GangOfFourの本によるOOカスタム設計は完璧なソリューションです。
- オプションで他のアプリにメッセージを送信します。フィルタ/インターセプタ、MDBメッセージ、CDIイベント、およびWebサービスも通知に役立ちます。
ユーザーがデータベース内のマスターデータを直接変更している場合は、次のいずれかを行います。
- アプリ内に単一の管理ページを提供して、マスターデータの更新を制御するか
- 個別のマスターデータ管理アプリを提供し、依存するアプリにメッセージを送信するか、
- （最善のアプローチ）品質（レビュー、テストなど）とタイミング（コード変更と同じように扱う）の観点からマスターデータの編集を管理し、環境を通じて宣伝し、データをデプロイして更新し、アプリを管理対象の小屋に再起動します >
別のアプリによって管理されているトランザクションデータを監視している場合（共有データベース統合）、またはETLなどのデータレベルの統合を使用してアプリケーションにデータを提供している場合：
- 1つのアプリだけでデータエンティティを作成するようにしてください（他のアプリは読み取り専用）
- 何がいつ変更されたかを理解するためのステージング/ETL制御テーブルのポーリングまたは
- 通知またはポーリングにJDBC/ODBCレベルの独自の拡張機能を使用します。これは、AlexPooleの回答または に記載されています。
- 2つのアプリからの重複するデータ操作を共有SOAサービスにリファクタリングすることで、監視要件を回避するか、データ操作からより高いレベルのSOA/アプリメッセージに引き上げることができます
- ESBまたはデータベースアダプターを使用して、通知用のアプリケーションまたはバルクデータ転送用のWSエンドポイント（Apache Camel、Apache ServiceMix、Mule ESB、Openadaptorなど）を呼び出します
- パイプや高度なキューイングなどのデータベース拡張インフラストラクチャの使用は避けてください
メッセージング（送信または受信）を使用する場合は、アプリケーションから使用してください。 DBからのメッセージングは、ちょっとしたアンチパターンです。最後の手段として、Webサービスを呼び出すトリガーを使用することができます（ http://www.oracle.com/technetwork/developer-tools/jdev/dbcalloutws-howto-084195.html ）ただし、これを非常に大まかに行うには細心の注意が必要です。きめ細かいCRUDタイプの操作を処理するのではなく、データセットが変更されたときにビジネス（サブ）プロセスを呼び出します。ジョブをトリガーし、トランザクションの外部でジョブにWebサービスを呼び出させるのが最適です。