大量のデータ用のデータベースを設計している最中ですが、主キーにどのデータ型を使用すればよいか疑問に思っていました。
テーブルのパーティション分割があり、データベースは最終的にクラスター化され、代替データセンターへのホット フェイルオーバーになります。
編集
テーブル - 複数の期間と物事についてチャットする複数のユーザーとチャットするための複数の期間と複数の事柄のチャットシステムを考えてください。
私が考えているのは指数関数的な問題です。つまり、何かが短期間に数十億行を生成する可能性があります。つまり、データベースや DBA が DBA のことを行う前に、
マーク - GUID に関するあなたの懸念を共有します - GUID が飛び交うコーディングは好きではありません。
あなたが提供したほんの少しの情報で、私はBigIntを使用することをお勧めします。これはあなたがこれまでに超えることはないであろう数である9,223,372,036,854,775,807まであなたを連れて行くでしょう。（INTから始めて、20億行を超えたときに簡単にBigIntに変更できると考えないでください。可能です（私はそれを実行しました）が、非常に長い時間がかかり、システムが大幅に中断する可能性があります。）
Kimberly Trippには、クラスター化インデックスの作成とプライマリーキーの選択に関する問題（関連する問題ですが、必ずしも完全に同じとは限りません）に関する優れた一連のブログ記事（主キーおよび/またはクラスター化キーとしてのGUIDとクラスター化インデックスの議論が続く）があります。 ）。彼女の推奨事項は、クラスター化インデックス/主キーは次のようにすることです。
キーおよびクラスター化されたインデックスとして増加するIDとしてBigIntを使用する場合、これらの4つの要件すべてを満たす必要があります。
編集：私が上で述べたキンバリーの記事（主キーおよび/またはクラスタリングキーとしてのGUID）は、（クライアント生成の）GUIDがクラスタリングキーに不適切な選択である理由について説明しています：
ただし、シーケンシャルではないGUID（クライアントで生成された値（.NETを使用）またはnewid（）関数で生成された値（SQL Server）など）は、ひどく悪い選択になる可能性があります-主に断片化のためベーステーブルに作成されますが、サイズが原因でも作成されます。不必要に幅が広い（intベースのIDの4倍の幅で、20億（実際には40億）の一意の行を提供できます）。また、20億を超える必要がある場合は、いつでもbigint（8バイト整数）を使用して263〜1行を取得できます。
SQLにはNEWSEQUENTIALID（）と呼ばれる関数があり、断片化の問題を回避するシーケンシャルGUIDを生成できますが、それでも不必要に幅が広いという問題があります。
いつでもintを使用できますが、パーティショニング/クラスタリングを考慮して、グローバルに一意のキーを生成するuniqueidentifierを調べることをお勧めします。
大量のデータが必要でない限り、 int が標準になる傾向があり、IDENTITYなどを扱う利点があります。Guid数値を推測不可能またはエクスポート可能にしたい場合は、いくつかの利点がありますが、Guid(「コーム」として自分で生成しない限り) を使用する場合は、クラスター化されていないことを確認する必要があります (インデックス、つまりファームではありません)。 ）、インクリメンタルではないため。
私はそのintが非常に良いと思います。
INTEGER の範囲は - 2147483648 ～ 2147483647 です。
UniqueIdentifier (GUID) を使用することもできますが、この場合は