1

つまり、基本的に私のデータベースには、ジョブのアプリケーションを格納するテーブルがあります。これらのアプリケーションには、ユーザーがドロップダウンメニューから、たとえば面接への招待やアプリケーションの成功に変更できるステータスがあります。また、アプリケーションごとにステータスが変更されたときと、それが何に変更されたかを保存する必要があるテーブルもあります。これを実行したいのは、OracleApplicationExpressに誰かのアプリケーションを表示するフォームがあることです。次に、編集ボタンをクリックしてステータスを変更できます。送信ボタンが押されたら、アプリケーションテーブルのステータスを更新するだけでなく、ステータスが変更された日付とステータスが変更された値を使用して履歴テーブルに新しいエントリを作成します。これにトリガーを使用しますか、それともOracleApplicationExpressで別の方法で実行しますか。

4

1 に答える 1

1

どちらでも構いません。どちらが適切かは、状況によって異なります。

  1. 履歴テーブルが、アプリケーション テーブルへのすべての変更を記録する単なるジャーナル テーブルである場合、履歴テーブルに挿入するアプリケーション テーブルの単純なトリガーに問題はありません。ただし、環境でトリガーが許可されていることを確認する必要があります (一部の DBA はそれらを好まない)。欠点は、トリガーを無効にできることです。これは、履歴テーブルが更新されず、アプリケーションが機能していないことに気付かず、ユーザーにエラーが発生しないことを意味します。利点は、どのアプリケーションがアプリケーション テーブルを更新しているか (Apex か他のクライアントか) に関係なく、履歴テーブルが維持されることです。

  2. ページが送信されたときに実行される 1 つ以上の PL/SQL プロセスを持つことができ、それらに任意の PL/SQL を入れることができます。たとえば、アプリケーション ステータスの更新とそれに続く履歴テーブルへの挿入です。これの利点は、コードが正常に実行されるか、エラーで失敗するかのいずれかであるため、履歴がアプリケーション テーブルと同期していることがわかります。これの欠点は、いわばフロントエンド コードでロジックがコーディングされることです。会社がアプリケーション テーブルを更新する別のインターフェイスを作成することを決定した場合、履歴が挿入されない (または同じように挿入されない) 可能性があります。

  3. これらの両方のアクションを実行する、アプリケーションのステータス変更用のラッパー プロシージャを記述します。Apex PL/SQL プロセスからこのプロシージャをコールします。このようにして、手順を他のシステムで再利用できます (必要になった場合)。

于 2012-12-06T05:55:41.027 に答える