Microsoft SQL Serverを使用していて、詳細の順序を保存する必要があるマスター/詳細シナリオがあります。したがって、詳細テーブルには、ID、MasterID、Position、およびその他の列があります。MasterIDとPositionにも一意のインデックスがあります。1つの場合を除いて、問題なく動作します。既存の詳細があり、順序を変更した場合です。たとえば、位置3の詳細を位置2の詳細に変更した場合、位置2（データベース内の位置は3に等しい）の詳細を保存すると、SQL Serverは、インデックスの一意性の制約のために抗議します。
この問題を合理的な方法で解決するにはどうすればよいですか？
よろしくお願いします
LukaszGlaz
これは古典的な問題であり、答えは簡単です。アイテム3を位置2に移動する場合は、最初に2のソート列を一時的な数値（99など）に変更する必要があります。したがって、次のようになります。
Move 2 to 99
Move 3 to 2
Move 99 to 3
ただし、一時的な値が通常の処理で使用されることはなく、該当する場合は複数のスレッドを尊重することに注意する必要があります。
更新：ところで-「複数のユーザーが順序を変更している可能性がある」問題に対処する1つの方法は、私が行うことです。各ユーザーに番号IDを付けてから、これを一時的な番号に追加します（私のスタッフIDは実際には一意のIDです）ログインのゲートに使用されるスタッフテーブルのフィールドID）。したがって、たとえば、ポジションがマイナスになることがない場合は、一時的な値として-1000-UserIDを使用できます。ただし、1つだけ信頼してください。衝突が発生することはないと想定したくないということです。それが発生したと思った場合、デバッグは非常に困難になります。
更新：GUZは、ユーザーが広告申込情報のセット全体を並べ替えてバッチとして送信した可能性があることを指摘しています。これは、2つのレコードを切り替えるだけではありません。次に、2つの方法のいずれかでこれにアプローチできます。
まず、セット全体の既存の並べ替えフィールドを衝突しない値の新しいセット（たとえば、-100-（staffID * maxSetSize）+ previousOrderVal）に変更してから、レコードごとに移動して、各レコードを新しいものに変更できます。オーダー値。
または、基本的に、orderVal値が配列インデックスと同等である配列のバブルソートのように扱うことができます。これはあなたにとって完全に理にかなっている（そして明白である）か、解決策1（とにかく簡単です）に固執する必要があります。
注文列の一意性制約を削除し（ただし、インデックスキーは残す）、必要に応じてコードの一意性を確保することができます。