私は、明示的な人間の相互作用によって各ステップで完全に駆動されるワークフロー システムを作成しています。つまり、タスクが人に割り当てられ、その人がいくつかの限られたオプション {承認、拒否、転送} から選択し、次の人に送信されるか、終了されます。
Oracle Streams/AQ が、通常の Web アプリケーション コードによって管理されるフラットなテーブルに対して提供できるものがあるかどうか、ちょっと興味があります。各アクションの後の処理量はかなり制限されており、ボリュームもそれほど大きくないため、キューに投入してスロットルする必要はありません。キュー構造を導入する利点は何ですか? または、私の状況ではやり過ぎですか?
キューイングの大きな利点は、他の方法では非常に難しい同時実行の問題 (処理のためにこのレコードを 1 つだけ表示する) を非常に簡単にできることです。キューイングがなければ、そのような動作を試すことはできますが、確実ではありません。最終的には、中間状態の更新と失敗したスレッドのチェックを何度も行う必要があります。
10g 以下では、Oracle は、SKIP LOCKEDエンド ユーザーが許可されていない構文を使用して、トランザクション デキュー操作を実装していました。11g では、その構文が公開され、AQ の実装を必要とせずに、人々がその問題を解決できるようになりました (次のレコードを見せてください)。
AQ の 2 つ目の利点は、キューのクリーンアップが非同期であることです。
AQ の大きな欠点は、サイズとメンテナンスです。単一の永続的なキュー/トピックに対して 7 つのテーブル/IOT のオーダーで作成することになり、それらのデータベース オブジェクトを直接維持することはできませんが、次の方法でメンテナンスを行う必要があります。 DBMS_AQ および DBMS_AQADM パッケージ。
待ち行列システムが有益である理由はたくさんありますが、それらがあなたの状況に当てはまるかどうかはわかりません. 単一のシステムがすべて単一のデータベースに格納されているようです。そのため、キューイングが通常のテーブルよりも有利になるとは思いません。
AQ が利点を提供する状況には、次のようなものがあります。 - 異なるシステム (複数のデータベース) が互いに通信するためのメカニズムとして
あなたが説明したように、単一のシステムで状態を管理する方法として、Streams/AQ はやり過ぎだと思います。
アプリケーションのボリュームが実際にそれほど大きくなく、数分のレイテンシーが許容できると想定している場合は、両方を避けて、古い学校のトリガーを使用して独自のログ テーブルにデータを入力します。次に、これらを pl ジョブで処理します。すべては、AQ がもたらす追加機能/複雑さを回避するためです。