競合状態のないSQL ServerでのIDの使用

プライマリキーのIDENTITY（1,1）の患者テーブルがあるとします。 @@ Identityを使用することで、2人で同時に新しい患者を救うことができる競合状態をどう回避するのですか？明らかに、Patientsテーブルの重複したIDは作成されませんでしたが、挿入された患者のIDが別のテーブルのレコードを別の場所に更新する必要がある場合はどうなりますか？両方のレコードが同時に挿入された場合、@@ Identityが他のレコードのIDを取得しないことをどのように知ることができますか？競合状態のないSQL ServerでのIDの使用

これを避けるためのベストプラクティスはありますか？

JamesNT

出典

2016-10-19 JamesNT

まず、@@ IDENTITYではなくSCOPE_IDENTITY（）を使用します。あなたはどんな競争状態を話していますか？ 1つのインサートが勝ち、最初の行が得られ、次にもう1つのインサートが続きます。各インサートは独自のSCOPE_IDENTITY（）値を取得しますが、一方のインサートが他方のインサートを取得することはできません。 –

はい、ベストプラクティスがあります。 @@Identityは使用しないでください。

insertステートメントで割り当てられたID値を取得する最も安全な方法は、OUTPUT句を使用することです。 documentationから始めてください。

これは多くの利点があります：

それがトリガーとネストされたステートメントによって混乱しませんが。
複数のインサートを同時に扱うことができます。
ID列だけでなく、他の列の値も返すことができます。
これは特に、トランザクションの影響を受ける行を返すので、セッションやユーザーなどについては考慮しません。

出典

2016-10-19 18:45:23

SCOPE_IDENTITYとOUTPUTの間に繋がっているようです。 – JamesNT

どうやってこのネクタイを壊しますか？ – JamesNT

私は両者が動作するように見えるので、両方の答えをチェックできるようにする必要があります。 – JamesNT

@@ IDENTITYは、競合状態が発生することはありませんが、それはどちらかのベストプラクティスではありません。代わりにSCOPE_IDENTITYを使用する必要があります。

http://blog.sqlauthority.com/2007/03/25/sql-server-identity-vs-scope_identity-vs-ident_current-retrieve-last-inserted-identity-of-record/

出典

2016-10-19 18:45:22

私はINSERTを行いますが、SCOPE_IDENTITYでSELECTを実行する必要があります。質問：INSERTの完了とSELECTの実行の間に、誰かがレコードを挿入しないという可能性をどうやって処理するのですか？私がn00bのように聞こえるならば、お詫び申し上げます。 – JamesNT

あなたはそれについて心配する必要はありません。別のプロセスが行を挿入している場合は、別の接続になります...したがって、スコープは完全に異なります。 –

競合状態のないSQL ServerでのIDの使用

答えて

関連する問題