フロントエンドとして.NET/C＃を使用し、バックエンドとしてSQLServer2008を使用しているアプリケーションを使用しました。常にトランザクションがc＃コードで処理されることがわかりました。ストアドプロシージャ内でトランザクションを使用してはならないという、このプロジェクトの不文律のようです。
個人的には、コードをより細かく制御できるため、トランザクションはストアドプロシージャ内で処理する必要があると感じています。開いているトランザクションは必要ありませんが、スクリプト内で多くの検証が行われる可能性があります。挿入/更新/削除を実行する直前にトランザクションを開く必要があり、できるだけ早く閉じることができます。
トランザクションを処理するためのベストプラクティスを理解するのに役立つ回答を探しています。正確にいつ、ストアドプロシージャ/ C＃内のトランザクションを選択する必要がありますか。
厳格なルールはありませんが、ビジネス層からトランザクションを制御する理由はいくつかあります。
データストアの境界を越えたコミュニケーション。トランザクションはRDBMSに対してである必要はありません。彼らはさまざまな実体に反対することができます。
呼び出している特定のストアドプロシージャでは使用できない可能性のあるビジネスロジックに基づいてトランザクションをロールバック/コミットする機能。
単一のトランザクション内で任意のクエリのセットを呼び出す機能。これにより、トランザクション数について心配する必要もなくなります。
個人的な好み：c＃には、トランザクションを宣言するためのより洗練された構造、つまりusingブロックがあります。比較すると、ロールバック/コミットにジャンプするとき、ストアドプロシージャ内のトランザクションは常に面倒であることがわかりました。
開いているトランザクションは必要ありませんが、スクリプト内で多くの検証が行われる可能性があります。挿入/更新/削除を実行する直前にトランザクションを開く必要があり、できるだけ早く閉じることができます。
これは、開かれているトランザクションの数に応じて問題になる場合とそうでない場合があります（これが単一のジョブなのか、高い同時実行性で実行されるプロシージャなのかは明確ではありません）。オブジェクトにどのロックが設定されているか、およびそれらのロックがどのくらいの期間保持されているかを確認することをお勧めします。
検証がロックされる可能性があることに注意してください。検証してからアクションが発生するまでの間にデータが変更された場合はどうなりますか？
問題がある場合は、問題のある手順を2つの手順に分割し、の外部から1つを呼び出すことができますTransactionScope。