Oracleトリガーよりも優れたアプローチ

Question

テーブル 'tab1'のいくつかのカラムをいくつかの値（別のテーブル 'tab2'から取得可能）で更新することになっています。今、 'tab1'は、（MQから別のシステムで）数秒ごとに新しいレコードを挿入しています。 'tab1'に新しいレコードが追加されるとすぐに 'tab1'を更新するソリューションを設計したいと考えています。レコードが追加されたのと同じ瞬間に完了する必要はありませんが、更新が早ければ早いほど良いでしょう。

1）最初に、tab1に「before insert」トリガーがあると思ったので、レコードを更新することができましたが、その設計はArchitectによって徹底的に審査されました。組織はデータベーストリガーの使用を許可していません（理由はわかりませんが、それは制限されています）。

2）次に実行するストアドプロシージャを作成します'tab1'のレコードの更新。このストアドプロシージャは、シェルスクリプトから長時間実行されるループ内で呼び出されます。すべての反復の後、3秒間の休止があり、次のループが開始され、再びストアされたprocが呼び出されます。この仕事は午前12時から午後11時59分まで実行され、毎晩再開されます。

私の質問です - これにはデータベースのみの解決策はありますか？他のソリューションも歓迎ですが、デザインのシンプルさは大きなプラスになります。ある同僚は、データベース内でジョブを実行する「トリガーのような」ソリューションがあるかどうか疑問に思っていたので、シェルスクリプトを書く必要はありません。

何か指摘します！

Answer 1

1. 明白な解決策をトリガします。

2. DBMS_SCHEDULER別の明白な解決策。

3. Continuous Query Notificationこれは、 "トリガーのような" 解決策になります。これは、特定のクエリの結果が異なる場合にアプリケーションを呼び出すことを意味します。しかし、アプリケーションではなくPL/SQLを呼び出すことができ、問合せは単純にselect * from tab1;になります。通常、私は建築家がこの解決策を見て、「トリガーはずっと簡単になる」と言いたいと思います。

4. DBMS_JOBSこれはDBMS_SCHEDULERの古いバージョンであり、それほど良くありません。しかし、それは違うし、不正な機能として捕らえられないかもしれない。

5. アーキテクトを無視する問題は、彼がトリガーやジョブを使用していることを拒否しているということではありません。 かもしれないこれらの技術を禁止する正当な理由になります。問題はなぜそれが許されなかったか明確に明言せずに健全なアイデアを拒絶したことである。彼がデータベースを理解したり、あなたのプロジェクトを気にかけたり、プロフェッショナルのように行動したりしたら、「ああ、申し訳ありませんが、これを行う典型的な方法だとわかっていますが、 X、Y、Zの "

Answer 2

ご質問にお答えください：

Q：これにはデータベースのみのソリューションはありますか？

あなたのアーキテクチャにはすべての制限があります。

Q：任意の他の溶液も、あなたの可能性の高いソリューションは、アプリケーションが正常にトリガやストアドプロシージャによって処理されるもの取り扱う持っているようです

を歓迎しています。 1つのトランザクションですべてを実行します。