レコードを更新するときに、2人のユーザーが誤ってお互いを上書きするのを防ぎたいです。つまり、2人のユーザーがレコードAを含むページをロードします。ユーザー1はレコードをABに更新し、ユーザー2はレコードをACに更新します。
最後にデータベースにヒットしてオーバーライドしたいだけではありません。レコードが更新されたため、保存できないというメカニズムが必要です。
今私が持っている2つのアイデアは、レコードにタイムスタンプを付けてそれを確認することです。一致しない場合は、更新を許可しないでください。2番目の方法は、更新が実行されるたびにレコードをGUIDし、GUIDを確認し、一致しない場合は更新しないことです。
これらの方法のいずれかが有効である場合は、どちらが最適ですか。そうでない場合、あなたは何を提案しますか。違いが生じる場合、これはC＃です
ありがとう
あなたが言及した2つの方法は事実上同等です-どちらの方法でも、「チェックアウト時の記録」の一意の識別子を効果的に取得します。タイムスタンプは明らかに、レコードがいつ有効であったかに関するデータの追加の利点を提供しますが、どちらが優れているかについての特定の見解はありません。
別の方法は、以前の値が何であったかを記憶し、それらが一致する場合にのみ更新を許可することです。そうすれば、ユーザーAがレコードの編集を開始し、ユーザーBが入って何かを変更し、それを元に戻しても、ユーザーAの編集は引き続き有効です。 。
これらの手法の用語は、楽観的ロック（または楽観的同時実行制御）です。
実際には3番目の方法があります。更新を行うには、次の形式の更新ステートメントを発行します。
UPDATE table SET update_field = new_value
WHERE db_pk = my_pk // assume primary key immutable
AND update_field = original_field_value
ここで、original_field_valueは、更新が試行される前のフィールドの値です。他の誰かがupdate_fieldあなたと同じ値に変更しない限り、この更新は失敗します。
あなたは、有効で有用な手法であるオプティミスティックロックについて説明しています。
どちらの方法もチェックに有効です。
どちらが最適かについては、アプリのサイズと、それぞれを実装するのにかかる時間を確認する必要があります。したがって、これがたまにしか発生しない場合は、より迅速な解決策を探して、タイムスタンプオプションを実装することをお勧めします。
より詳細なグーグル同時実行性が必要な場合-ここから始める記事-concirrency
私は最初のオプションを使用しています。更新のたびにタイムスタンプを更新します。したがって、更新時に、タイムスタンプが等しいかどうかを確認します。
楽観的および悲観的なロックという用語はベルを鳴らします。これらは、あなたが説明している問題に対する2つの認識されたアプローチです。Web環境で作業しているようです。この場合、前者のオプション（楽観的ロック）がより適切です。これは、これが一般的にどのように実装されるかについて説明しました。タイムスタンプまたはバージョン番号を使用して、レコードが取得されてからレコードが更新されているかどうかを確認するのが一般的です。考慮すべきもう1つのことは、基になるデータに変更があったことをユーザーに知らせ、保存しようとしたものと別のユーザーが保存したもののどちらかを選択できるようにすることです。この選択は、実際にはビジネスルールが何であるかに依存します。