ネガティブキーは何に使用されますか？
標準のSQLデータベースを使用するのはやや新しい（現在はほとんどがMySQLで動作している）私は、現時点でこれを多くの使用方法で実行していません。
テーブルにインデックスを付ける負の（または、むしろ署名された）キーがあると便利なのはいつですか？
すべての主キーは、レコードで最も重要な値であると判断した値です。その鍵が署名付き整数、署名なし整数、文字列、BLOB（実際には制限があります）、UUID（または今日の名前）のいずれであっても、それが鍵であることは事実であり、最も重要なこと。
キーには正の数値のみを使用するように制限されていないので、signed intは〜20億になり、unsigned intは〜40億になると考えるのは理にかなっています。ただし、signed intを使用して、初期値を〜-20億に設定し、増分を1に設定しても問題はありません。 20億レコードを超えると「ゼロ」に到達し、その後20億レコードに達します。
テーブルに「負のキー」があると便利な理由は、「テーブルにキーがあると便利な理由」と同じです。キーの「値」は、キーとしてのステータスには影響しません。キーはキーですキーはキーです。
重要なのは、キーが有効かどうかです。
否定的なキーを許可すると便利な理由について、いくつかの理由を提案できます。
正の販売注文番号と一致する負の販売注文番号として販売システムの返品を示し、相関を容易にする場合（これは単純で設計が不十分ですが、「スプレッドシート」の意味で機能します）。
Usersテーブルを用意し、負の数のテーブルがシステムで制御されていることを示したい場合はどうでしょう（SOはこれをまさにチャットフィードユーザーに対して行います）。
私は続けることができますが、実際に負の数が重要である唯一の理由は、あなたまたは私がそれを重要視するかどうかです。それ以外に、キーの値がキー自体に何らかの影響を与える大きな理由はありません。
ID列または自動番号列について考えている場合、値自体に意味はありません。 （時々それは私が自分自身の前に行ったdrachensternによって言及されたSOのチャットユーザーに従って）
ただし、通常、符号付き整数を使用すると、範囲の半分が失われます。
参照： テーブル内のフィールドが最大の符号付きまたは符号なし32ビット整数に近づいた場合の対処方法
別の例：小規模なレプリケーションシナリオでは、1つのサイトに負の値を使用し、別のサイトに正の値を使用すると、特定の行のソースについて暗黙の知識が得られます。
すべてのデータベースシステムが符号なし整数型をサポートしているわけではなく、MSSQLはサポートしていない整数型の1つです。これらの場合、負の値はタイプで可能であるという理由だけで整数キーフィールドで可能です（ この例 に示すように、ルールまたはトリガーを使用してそれらをブロックできますが、おそらく追加する必要はありませんそのようなルールをすべてのインター/更新に適用するオーバーヘッド。
データベースに関する限り、テーブル内で一意である限り、主キーの実際の値は重要ではありません。それに対して、42と42は42と69と同じように2つの異なる数値にすぎません。つまり、コードによって値の否定性または否定性にのみ意味が与えられます。
符号なし整数型をサポートしないことは、おそらく、複雑さの軽減に基づいた設計上の決定です。つまり、2つの異なる32ビット整数型がそれらの間に値を割り当てるときに範囲のチェックについて心配することを望まないことです。それは、0または1から始まる自動インクリメントフィールドで可能なインデックスの数を、符号なしの型で可能であるもの（〜4e9ではなく〜2e9）の半分に制限しますが、これはめったに重大な問題ではありません（必要になる可能性がある場合）とにかく64ビットタイプの場合に特に重要な値の数（特に、そのような値が32ビットよりも効率的に処理される64ビットアーキテクチャを使用している場合）スペース上の理由から32ビットに固執するには、増分を-2,147,483,647から開始できます。