ご存知のように、SQL Serverでは、IDENTITY (n,m)は値がから始まりn、増分値はですが、すべてのデータベース設計者が、からのintデータ型のすべての値を利用せずにmID列をとして作成することに気付きました。IDENTITY(1,1)(-2,147,483,648) to (2,147,483,647)
すべてのID列をとして作成することを計画していますIDENTITY (-2,147,483,648, 1)（ID列はアプリケーションユーザーから非表示になっています）。
それは良い考えですか？
20億の値では不十分であることがわかった場合は、40億でも不十分であることがわかります（プロジェクトの存続期間中に、最初に設計されたものの2倍以上の値が必要になることはほとんどありません）。まれな*）ので、まったく別のアプローチを取る必要があります（おそらく長い値、おそらくまったく異なるもの）。
そうでなければ、あなたはただ奇妙で読めないだけで利益がありません。
また、たとえばアイテム312が特定のものをテストするためのいくつかの優れた特性を備えていることを知っているデータベースを持っていないのは誰ですか？頭の中で任意のIDが焼き付けられていることはわかっています。彼らはそれを「彼らが2度名前を付けたのでとても良い」と呼ぶかもしれませんが、私は常にニューヨークを「都市657、私たちのテストケースのほとんどをカバーしている」と知っています。これは速記にすぎませんが、-2147482991はそれほど便利ではありません。
*それに少し追加します。いくつかのことで、あなたは「ああ約100」と言うかもしれません、そしてそれが実際に110であるとわかるかもしれません、大丈夫です。他の人と一緒に、あなたは実際にそれが実際に100,000であることに気付くでしょう-あなたは桁違いに外に出ていました。数値が大きいほど、この種の間違いが頻繁に発生します。これは、数十億の見積もりが数十の回答になる問題とは異なるという種類の問題が原因です。特定のケースで200が最大であると見積もった場合、おそらくさらに数百の余地を残す必要があります。特定のケースで20億を見積もる場合、おそらくさらに数兆の余地を残す必要があります。とは言うものの、誰かが実際にマイナス20億でIDを開始するのを見たのは、最終的に約3,000行になりました。
SQL Server側では、負のIDは問題なく、正の数のように処理されるため、これを行うことができます。
他の人は正しいです、あなたは別の提案について考える必要があります、しかし主要な問題はあなたのデータベースに接続されたアプリケーションです。
MS環境を取るとしましょう。次に例 を示します。.NETDataSetは、自動インクリメントされたIDで負のIDを使用して、コードの変更を追跡しています。したがって、問題が発生する可能性があります。理由は次のとおりです。
負のキーは、行の一時的なインスタンスに使用されます。
ここにリファレンスがあります：MSDN
したがって、間違いなく、MS環境でMSSQL用にこのようなデータベースを設計することはお勧めできません。
コード内にテーブルを表すクラスがある場合（これは発生する可能性が非常に高いです）、新しいオブジェクトを作成するたびに、デフォルトでID0が割り当てられます。ID 0がすでに割り当てられている場合、データベース内のデータを上書きするミスが発生する可能性があります。これにより、オブジェクトが新しいのか、それともデータベースからのものなのかを簡単に判断できます。if (myObject.ID != 0)
ゼロに近い整数を操作することの「優れた」副作用の1つは、特にデバッグと単体テストを念頭に置いて、開発者やテスターなどが見やすく、覚えやすいことです。
また、代理キーにはビジネス用語に忍び寄る厄介な習慣があります。たとえば、ユーザーはブラウザの上部にあるURLクエリ文字列にPKが表示される可能性があります。数字の桁数が多いほど、何かを誤って引用する可能性が高くなります。ヘルプデスククエリで。
したがって、これが、自分のIDを-2147483231ではなく1にシードすることに非常に満足している理由のひとつです。代わりに、@ Jonが示唆するようにBIGINT、2つ以上が必要になる可能性があるときはいつでも上に移動します。私のテーブルには10億行あります。
負の数から正のIDに移行すると、ゼロを超えます。つまり（実際に数十億行を挿入していると仮定すると）、最終的には識別子がゼロになります。これは本質的に悪いことではありませんが、ORMツールの潜在的なエッジケース、またはゼロとヌルを区別するのが難しい単純にずさんなアプリケーションコードを提示する可能性があります。
負のIDは、テスト目的でダミーデータを実際のデータと混合し、テストが完了したら破棄する必要があるライブ環境でのテストに役立ちます。これは非常に正当な理由がある場合にのみ行う必要があります-私はこのテクニックを一度しか使用していません。
負のIDは、単一行の読み取り専用テーブルでの管理者の目的にも役立ちます（つまり、トランザクションがなく、実行可能SQLがテーブルで実行されません）。
これらの特定の目的は別として、ID値<= 0は、光よりも多くの熱を生成します。
さらに、MS Docs（https://docs.microsoft.com/en-us/sql/relational-databases/in-memory-oltp/implementing-identity-in-a-memory-optimized-table？ view = sql-server-2014）、IDENTITY（1、1）はメモリ最適化テーブルでサポートされています。ただし、IDENTITY（x、y）が定義されているID列（x！= 1またはy！= 1）は、メモリ最適化テーブルではサポートされていません。
したがって、私の意見、および他のユーザーによってほのめかされた他の理由では、IDENTITY（1、1）は、メモリ最適化テーブルに対してより実用的でメモリ効率が高いです。
INT IDENTITY（1、1）から始めて、最大になったら、次の手順に従ってBIGINTに「アップグレード」できます。
PKをBIGINTにアップグレードします： ALTERTABLE[dbo]。[tbName]ALTERCOLUMN [dbo.Id] BIGINT
PK制約を再作成し ます。ALTERTABLE[dbo]。[tbName]ADDCONSTRAINT [PK_tbName_Id] PRIMARY KEY CLUSTERED（[Id] ASC）
これがお役に立てば幸いです。