2

Oracle 10g では、操作 (挿入、選択、更新、削除) ごとにテーブルごとに 1 つのストアド プロシージャがあります。実際には、操作ごとにテーブルごとに複数のプロシージャが存在する可能性があります。たとえば、select の場合は、SelectList、SelectOneRecord、Search (動的クエリを使用) です。

これらのプロシージャにはトランザクションはありません。

1 つのトランザクションで複数の操作を組み合わせる必要がある場合があります。たとえば、あるテーブルへの挿入と別のテーブルへの更新を、すべて 1 つのトランザクションで行います。このために、トランザクションを持つ別の手順を作成します。次に、このプロシージャは 2 つのプロシージャを呼び出します。

上記の単一トランザクション内のプロシージャー呼び出しの組み合わせを有効にするために、上記で説明したように、トランザクション動作をプロシージャーに入れません。

ほとんどの場合、1 つのテーブルへの挿入など、1 つの操作のみを実行する必要があります。挿入プロシージャにはトランザクション動作がないため、トランザクション動作を持つ別のプロシージャを作成し、そのプロシージャが挿入プロシージャを呼び出す必要があります。

最終的には、多くの基本的な手順 (1 つのテーブル、1 つの操作) と、基本的に基本的な手順のラッパーである多くのトランザクション プロシージャが作成されます。

私の質問は、基本的な手順で条件付きのトランザクション動作を行う方法があるかどうかです。これは、トランザクション ロジックを配置できる if 条件を意味し、渡したパラメータに基づいてトランザクションの動作をオンまたはオフにすることができます。次に、テーブルへの挿入など、操作を 1 つだけ実行したい場合は、トランザクション動作を使用して基本的な手順を呼び出します。また、1 つのトランザクションで 1 つのテーブルに挿入し、別のテーブルに更新するなど、1 つのトランザクションで 2 つのプロシージャを呼び出したい場合は、別のトランザクション プロシージャを作成し、トランザクション動作なしで 2 つの基本的なプロシージャを呼び出します。

以下は、別のプロシージャを呼び出してトランザクションでラップするトランザクション プロシージャです。

BEGIN
    SAVEPOINT the_start;

    BasicProcedure(<list of parameters>);

    COMMIT;

    EXCEPTION
         WHEN OTHERS THEN

         BEGIN
             ROLLBACK TO the_start;
             RAISE;
         END;
END;

セーブポイント行とコミット行を if ステートメントに入れることはできますが、例外ブロックを if ステートメントに入れることもできます。例外ブロックを if ステートメントに入れる必要がありますか? プロシージャで例外をキャッチすると、例外が発生したときに自動的にロールバックされますか?

4

1 に答える 1

6

あなたが書いたものはテーブルAPIと呼ばれます。一部の人々は彼らを罵倒し、他の人々は彼らを麻酔します。テーブルAPIの場合は、基本的にモジュール性とコードの再利用です。反対のケースは主にパフォーマンスです。特注のSQL結合がより効率的である場合、行ごとまたはテーブルごとの処理を推奨します。

個人的に私は柵の両側に立っていました。現在、私は調整されたコードを好みます。それにより、トランザクションの操作が容易になります。

それはあなたの状況に私をもたらします。テーブルAPIは汎用的であり、すべての状況で使用できると想定されています。つまり、トランザクションの管理を制御することはできません。これは、TableAPIメソッドを呼び出すプログラムに適切に属します。これらのプログラムは、ビジネスロジックを実装するコードです。ビジネストランザクションは、作業単位を構成するいくつかのアクティビティで構成されます。トランザクションを成功させるには、これらすべてが成功する必要があります。そうでない場合、ビジネストランザクションをロールバックする必要があります。Table APIコマンドが独自のコミットを発行する場合、その後の失敗により、ビジネストランザクションは一貫性のない状態になります。 ACIDは、このレベルと個々のSLレベルで適用されます。

これは、実際には、特注のSQLを使用してストアドプロシージャを作成することと同じです。

「ビジネスロジックトランザクションをストアドプロシージャにすることを提唱しているのかどうかは、私にはわかりません。」

これはカバーする領域が広く、ビジネスロジックよりもPL/SQLアプリケーションを設計する必要があります。（タイムマシンにアクセスできる場合は、Open World 2009に戻って、「意図的なPL / SQLの設計」に関する私のプレゼンテーションを聞く必要があります）

しかし、大まかに言えば、そうです。PL/ SQL層の外向きの側面は、作業単位、つまりビジネストランザクションを中心に編成されたビジネスロジックAPIで構成されている必要があります。

「そのような手順は自律的なトランザクションですか？」

絶対違う。自律型トランザクションは、アクティビティのログ記録と監査という1つの目的にのみ適合します。この場合、より広いトランザクションに影響を与えることなく、発生したことを永続的に記録する必要があります。そのプラグマの他の使用法は、発生するのを待っている応急修理またはデータ破損のバグです。

商取引は純粋で単純な取引です。ストアドプロシージャがコミットを所有するか、それ以外の場合は呼び出し元のプログラムにそれを延期する必要があります。

于 2012-06-30T21:05:02.797 に答える