0

ストアドプロシージャが次のBEGIN/COMMITTRANを使用していることに気づきました。 

BEGIN TRAN
  INSERT INTO SomeTable
     (
         TypeID
     )  
  VALUES
     ( 
         @TypeID
     )
    SET @OvID = SCOPE_IDENTITY() 
 COMMIT TRAN

INSERTおよびSCOPE_IDENTITYでトランザクションを使用することは良い習慣ですか？

このようにTRANを使用すると、INSERTプロセスが大幅に遅くなりますか？

失敗する可能性のあるステートメントが複数ある場合（つまり、2つのINSERTのように）、トランザクションを使用することを常に考えています。この場合、INSERTが失敗しているのがわかりますが、SCOPE_IDENTITYは常に成功すると思います。

4

3 に答える 3

3

単一のステートメントの場合、追加の原子性や信頼性が得られないという点で、それは実際には重要ではありません。またSCOPE_IDENTITY()、現在のバッチ以外の影響を受けることはないため、TRANSブロックでラップしても影響はありません。

入るのが良い習慣であるかどうかはかなり主観的であるため、私は意図的にそれに対処していません！

于 2012-04-24T18:06:03.467 に答える
2

トランザクションにはオーバーヘッドがあり、クエリ時間が遅くなります。シングルインサートの場合、それは必要ありません。挿入が失敗した場合、scope_identityはnullになります。

于 2012-04-24T18:07:16.627 に答える
2

最後のポイントは、「成功」の意味によって異なります。挿入が失敗した場合、エラーの性質やスコープ/バッチで発生している他の何かに応じて、割り当ては行われますが、@OvIDになりますNULL。

トランザクションにはいくらかのオーバーヘッドがあります（ループでこれを何千回も実行するまで、違いに気付くとは思えません）。ただし、これが進行中のプロジェクトのコードである場合、トランザクションラッパーは意図を説明するのに役立つ場合があります。たとえば、後で来る可能性のあるステートメントがさらにある場合、この単一ステートメントのアトミックトランザクションはなくなります。TRY/CATCHエラー処理やその他のエラー処理に煩わされることはないのであれば、トランザクションに煩わされるのはおかしいようです。孤立したtxをなんらかの形で残してしまった場合に備えて、フォールバックを常に処理したいと思います。障害の原因と重大度によっては、奇妙なことが起こる可能性があります。

于 2012-04-24T18:16:57.097 に答える