ネットワーク上で実行される単純なクライアント登録システムがあります。システムは、現在の年を連結した一意の 3 桁の ID (主キー) を生成することになっています (例: 001-2013)。しかし、(LAN 経由で) 異なるコンピューターから 2 人のユーザーが異なるクライアントを登録しようとすると、同じ主キーが生成されるという問題が発生しました。
ID が既に生成された後で、ユーザーが登録をキャンセルした場合はどうなりますか? その ID を別のクライアントに再利用する必要があります。静的変数について読みましたが、問題は解決しませんでした。あなたのアイデアに本当に感謝しています。
一意で連続した ID は実装が困難です。それを完全に実現するには、クライアント情報のコミット作成をシリアル化して、データが実際に保存されたときにのみIDが生成されるようにする必要があります。そうしないと、送信中に何か問題が発生したときに穴が開いてしまいます。
厳密な連番が必要ない場合は、各システムに ID の範囲 (1 ～ 22、23 ～ 44、...) を割り当てるのが一般的な方法です。できるだけ多くの ID を使用する必要がある場合は、範囲の代わりに使用する ID のリスト ({1,3,233,234}、{235,236,237}) を指定できます。
問題：
ID-001はどうする？
最も簡単な解決策は、アイテムが確実に保管されるまで ID を割り当てないことです。
別の方法として、最終的にアイテムを保存するときに、最初のフリー ID を検索します。ステップ 2 のアイテム (#2) がステップ 1 のアイテムの前に保存された場合、#2 は ID -001 を取得します。#1 が保存されると、保存ロジックは、要求された ID (-001) が使用されていることを確認するため、-002 を割り当てます。そのため、ID が再割り当てされます。
最後に、新しいアイテムを作成するときに、次のフリー ID を簡単に見つけることができます。上記の 3 つの手順では、最初に -001 があるはずの場所にギャップがあることを意味します。ここで新しいアイテムを作成すると、コードは -001 が未使用であることを認識し、それを新しいアイテムに割り当てます。
しかし、それはあなたが指定しなかった要件に完全に依存します。現在、-001 は -002 よりも後に作成されました。それが許可されているかどうかはわかりません。さらに、任意の時点で、アイテムがキャンセルされたナンバリングにギャップが生じる可能性があります. レポート期間の最後に発生すると、エラー (-033、-034、-036) が発生します。
この請求書番号などの代わりに、自動インクリメントの主キーを含めることもできます。