Autonumber フィールド (SQL Server の「ID」など) は、データベース テーブルに一意のキーを提供するための一般的な方法です。ただし、それらは非常に一般的であるため、将来のある時点で、それらが最大値に達し始める問題に対処する予定です.
このシナリオを回避するための推奨戦略を知っている、または持っている人はいますか? 多くの回答で GUID への切り替えが提案されると思いますが、これには大量の開発が必要になることを考えると (特に、多くのシステムが統合されて価値を共有している場合)、別の方法はありますか? 新しいハードウェア/オペレーティング システム/データベースでは、整数に対してますます大きな値を単純に許可する方向に向かっていますか?
ID がなくなることが本当に予想される場合は、 を使用してくださいbigint。ほとんどの実用的な目的では、これがなくなることはありませんuniqueidentifier。
毎秒30 億(つまり、3.0 GHz プロセッサでのトランザクション/サイクル) のトランザクションがある場合、使い果たすには約 1 世紀かかりますbigint(サインを少し先延ばししたとしても)。
それは、かつて、「640Kは誰にとっても十分なはずです.」 :)
次の関連する質問を参照してください。
受け入れられた/トップ投票された回答は、それをほぼカバーしています。
データベースから削除された番号を循環する可能性はありますか? それとも、ほとんどの記録はまだ生きていますか? ちょっとした考え。
私の他のアイデアは、bigintに切り替えるというMehrdadの提案でした
通常、ID 列は 1 から開始し、+1 ずつ増加するように設定されています。負の値は正の値と同じように有効であるため、使用可能な識別子のプールが 2 倍になります。
ID が上限に達するほど大量のデータを取得している可能性がある場合は、データベースの複数のインスタンスを何らかの方法で同期できるように、レプリケーションのサポートも必要になる場合があります。
そのような場合、および「推測可能な」ID (Web アプリケーションなど) を持たないようにしたい場合は、ID 列の代わりに新しい Guid のデフォルトで Guid (Uniqueidentifiers) を使用することをお勧めします。
Guid は一意であるため、レコードが同時にシステムに追加された場合でも、データを適切に同期できます。