私のチームでのかなり活発な議論で、私はほとんどの人が主キーとして好きなものを考えるようにさせられました。次のグループがありました
PKの最善のアプローチは何ですか？あなたがあなたの意見を正当化できればそれは素晴らしいでしょう。上記より良いアプローチはありますか？
編集：誰でも簡単にサンプル/アルゴリズムを使用して、適切にスケーリングできる行の人間が読める識別子を生成できますか？
回答:
時々接続するアプリを使用してデータベース間で同期を行う場合は、プライマリキーにGUIDを使用する必要があります。デバッグは少し面倒なので、その場合を除いて、自動インクリメントのintに固執する傾向があります。
自動インクリメントint型は、デフォルトであるべきであり、ないそれらを使用することは正当化されるべきです。
CHAR(1)も十分だったとしても、のようにsex。言うまでもなく、それは作業するのに悪夢でした。
本当に基本的なポイント（と私が考えるもの）を指摘する答えがありません。つまり、主キーは、同じ実世界のエンティティに対してテーブルに2つのエントリが取得されないことを保証するものです（データベースでモデル化された）。この観察は、主キーの良い選択と悪い選択を確定するのに役立ちます。
たとえば、（米国）州の名前とコードの表では、名前またはコードのいずれかが主キーである可能性があります-それらは2つの異なる候補キーを構成し、それらの1つ（通常はより短い-コード）が主キー。機能依存関係（および結合依存関係-1NFから5NFまで）の理論では、主キーではなく重要なのは候補キーです。
反例として、人間の名前は一般的に主キーの悪い選択になります。「ジョン・スミス」や他の似たような名前で行く人はたくさんいます。ミドルネームを考慮に入れても（覚えておいてください：誰もが持っているわけではありません-たとえば、私は持っていません）、複製の余地はたくさんあります。したがって、人々は主キーとして名前を使用しません。彼らは社会保障番号（SSN）や従業員番号などの人工的な鍵を発明し、それらを使用して個人を指定します。
理想的な主キーは、短く、ユニークで、覚えやすく、自然なものです。これらの特性のうち、一意性は必須です。実際のデータの制約を考えると、残りは柔軟でなければなりません。
したがって、特定のテーブルの主キーを決定する場合は、そのテーブルが何を表しているかを調べる必要があります。テーブル内の列値のセットは、テーブル内の各行を一意に識別しますか？それらは候補キーです。さて、各候補キーが4列または5列で構成されている場合、それらが（主に短さを理由に）良い主キーを作成するには不格好であると判断するかもしれません。そのような状況では、代理キー（人工的に生成された番号）を導入する場合があります。多くの場合（常にではありませんが）、代理キーには単純な32ビット整数で十分です。次に、この代理キーを主キーとして指定します。
しかし、あなたがしなければならない通常の列のものをセットにユニーク制約を置くことによって-まだ他の候補キーことを確認してください（代理キーのためにあまりにも候補キーと同様に、選ばれた主キーです）、すべての一意の識別子として維持されます。
行を一意にするものを特定するのが難しい場合がありますが、単に情報を繰り返すだけではそれが真にならないため、何かを行う必要があります。また、注意していないと同じ情報を格納することを意図して2つ（またはそれ以上）の行を取得し、情報を更新する必要がある場合、1つの行だけを更新する危険性（特にカーソルを使用する場合）があります。すべての行ではなく、行が同期していないため、どの行に正しい情報が含まれているかは誰にもわかりません。
これは、いくつかの点で、かなり固い見方です。
必要なときにGUIDを使用しても特に問題はありませんが、GUIDは大きくなる傾向があり（16〜64バイトなど）、頻繁に使用されます。多くの場合、完全に適切な4バイト値で十分です。4バイトの値で十分なGUIDを使用すると、ディスク領域が無駄になり、インデックスページごとの値が少なくなるため、データへのインデックス付きアクセスも遅くなるため、インデックスはより深くなり、より多くのページを読み取る必要があります。情報。
人々は普遍的な正しい答えを求めているので、これは宗教的な問題にすぎません。チームとこのSOスレッドの両方が非常に不一致を示しているという事実は、さまざまな状況で、説明したすべてのソリューションを使用する十分な理由があるという手がかりになるはずです。
state（CA、TX、NY）を格納する必要がある場合char(2)は、intではなく自然キーを使用することもできます。id完全に適切な複合キーが存在する場合は、不必要に" "代理キーを追加しないでください（これは特に多対多のテーブルに当てはまります）。すべてのテーブルで3列のキーを使用することは絶対にナンセンスです。この種の情報のソースとして、データベースプログラマーのブログが好きです。
主キーの3列？列にはビジネスルールの要求に応じて適切な一意の制約を設定する必要があると思いますが、それでも別の代理キーがあります。複合キーは、ビジネスロジックがキーに入るという意味です。ロジックが変更されると、スキーマ全体が台無しになります。
私は私のユニークなものが好きです。
少し話題から外れましたが、私はあなたと一緒にチャイムすることを強いられています...
主キーがGUIDの場合は、クラスター化インデックスにしないでください。GUIDはシーケンシャルではないため、データはほぼすべての挿入中にディスク上で再配置されます。（うん。）GUIDを主キーとして使用する場合、それらは非クラスター化インデックスである必要があります。
私は常に代理キーを使います。代理キー（通常はID列、自動インクリメント、またはGUID）は、データ自体にキーが存在しないキーです。一方、自然キーは、それ自体で行を一意に識別するキーです。私が人生で知ることができる限り、実際の自然の鍵はほとんどありません。米国のSSNのようなものでさえ、自然な鍵ではありません。複合主キーは、発生を待っている災害です。そのデータを編集することはできません（複合キーであるかどうかにかかわらず、自然キーの主な欠点です）。ただし、複合キーを使用すると、関連するすべてのテーブルにそのキーデータを永続化する必要があります。なんと巨大な無駄。
ここで、代理キーを選択するために、ID列を使用します（主にMS SQL Serverで作業します）。GUIDのはあまりにも大きく、マイクロソフトが推奨していますに対して PKとしてそれらを使用します。複数のサーバーがある場合、必要なのは、増分を10または20、または同期/拡張する必要があるサーバーの最大数と思われる数を増やし、後続の各サーバーの各テーブルのシードを追加することだけです。 、そしてあなたは決してデータの衝突を持つことはないでしょう。
もちろん、増分のため、ID列をBigInt（そうでなければlong [64ビット]とも呼ばれます）にします。
少し計算すると、増分を100にしても、テーブルに92,233,720,368,547,758（> 92兆）行ある可能性があります。
「プライマリ」キーというフレーズでの「プライマリ」という言葉の使用は、本当の意味では誤解を招くと思います。
まず、「キー」はテーブル内で一意でなければならない属性または属性セットであるという定義を使用します。
次に、任意のキーを持つことは、いくつかのしばしば相互に矛盾する目的に役立ちます。
テーブル内の特定のレコード/行をすばやく見つける必要があるクエリのパフォーマンスを向上させるため。
同じ論理エンティティを表す重複行がテーブルに挿入されないようにして、データの一貫性を確保します。（これは「自然な」キーと呼ばれることが多く、比較的不変のテーブル（エンティティ）属性で構成される必要があります。）
明らかに、意味のない、非自然なキー（GUIDや自動生成された整数など）は、完全に＃4を満たすことができません。
しかし、多くの（ほとんどの）テーブルでは、多くの場合、＃4を提供できる完全に自然なキーは複数の属性で構成され、非常に広いか、非常に広いため、目的＃1、＃2、または＃3に使用すると、受け入れられなくなります。パフォーマンスの結果。
答えは簡単です。両方を使う。他の子テーブルのすべての結合とFKに単純な自動生成の統合キーを使用しますが、データの整合性を必要とするすべてのテーブル（非常に少数のテーブルでは必要ありません）に、矛盾するデータ行の挿入を防ぐ代替の自然な一意のキーがあることを確認します。 ..さらに、常に両方がある場合、自然キーの使用に対するすべての反対意見（変更された場合はどうなりますか？それがFKとして参照されているすべての場所を変更する必要があります）は、そのためにそれを使用していないため、疑わしくなります。 ..一貫性のない重複データを避けるために、それをPKである1つのテーブルでのみ使用しています...
GUIDについては、インデックスでGUIDを使用するとインデックスの断片化を防ぐことができるため、GUIDの使用には十分注意してください。それらを作成するために使用される最も一般的なアルゴリズムは、GUIDの「ランダム」部分を最上位のビット位置に配置します...これにより、新しい行が追加されると、定期的なインデックスのデフラグ/再インデックスの要件が増加します。
してはいけないことの1つは、スマートキーを使用することです。これは、レコードに関する情報がキー自体にコード化されているキーであり、最終的にはあなたを噛みます。
私は1つの場所で作業しました。主キーは、文字と数字を組み合わせたアカウントIDでした。具体的なことは覚えていませんが、たとえば、特定のタイプのアカウントは600の範囲にあり、別のタイプのアカウントは400で始まります。顧客が両方を要求するまで、それは素晴らしいことでした仕事の種類。または彼らがした仕事の種類を変えた。
別の場所では、ツリー内の場所をレコードの主キーとして使用しました。したがって、次のようなレコードがあります。
Cat1.subcatA.record1
Cat1.subcatA.record2
Cat1.subcatB.record1
Cat2.subcatA.record1
もちろん、顧客が最初に望んだことは、ツリー内のアイテムを移動する方法でした。それが起こる前に、ソフトウェアのセット全体が死にました。
お願いします、維持しなければならないコードを書いているなら、スマートキーを使わないでください！
私は主キーとして自動インクリメントのファンです。私はこれが警戒犯であることを心の中で深く知っていますが、追加されたとき（ORDER BY ID DESC、f'rインスタンス）によってデータをソートすることをとても簡単にします。
3つの列は、人間が解析するには非常に厳しい音に聞こえます。
そして、それはトレードオフです-リレーショナル機能のどれだけが必要なのか、このテーブルをここで質問する人間が理解できるようにすることです（ストアドプロシージャまたはプログラムインターフェイスではありません）。
自動インクリメントは私たち人間のためのものです。:-(
主キーを構成する列が少なくとも3つあるはずです。
分かりません。
「生の名前」や「生年月日」など、「自然な鍵」について話していますか？自然キーが存在する場合は理想的ですが、自然キーの候補のほとんどは、一意ではない（同じ名前の人が数人）か、一定ではありません（誰かが名前を変更できます）。
Int / BigIntは、自動インクリメントで十分な主キーです。
私はギドが好きです。自動インクリメントの潜在的な問題は、値（たとえば、「注文ID」）がデータベースインスタンス（たとえば、「販売データベース」）によって割り当てられることです。複数のデータベースインスタンスによって作成されたデータをマージする必要がある場合（たとえば、それぞれが独自のデータベースを持つ複数の営業所から）。
RE GUID
これが本当に本当に本当に大きなデータベース、大量の負荷、高速アクセスになるかどうか注意してください。
私の最後の仕事では、1億から5億レコードのデータベースがありましたが、データベースの担当者はGUIDに対して適切なサイズの10進数を強く主張しました。彼らは、（Oracleでは）文字列Guidの内部ストレージのサイズの違いと、10進数の値との比較では、ルックアップに非常に顕著な違いがあると感じていました。（より大きなキー=トラバースするより深い木）
GUIDのランダムな性質により、インデックスページのFILL FACTORも大幅に減少します。これにより、ティアリングとディスクI / Oが劇的に増加します。
私は常に代理キーを使用してきました-「id」と呼ばれる自動インクリメント整数。別のオプションが明らかな場合でも、これを行う理由はたくさんあります。
...そして次のことをしない合理的な理由はありません：
私がまだ考えていない、または出くわしていないことに対する賢明な理由はいつでも歓迎されます...
自動インクリメントのintまたはGUIDのみを使用しています。自動インクリメントintを使用した時間の99％。これは、データベースについて初めて知り、データベースを使用しない理由に遭遇したことがないときに使用するように教えられたものです（GUIDの方が優れている理由は知っていますが）。
自動インクリメントintは読みやすさを向上させるため、私は好きです。たとえば、「レコード129383を見てください」と言うと、だれかが簡単に見つけて見つけることができます。GUIDを使用すると、ほとんど不可能です。
基本的な定義の答えを過ぎて、良い主キーを構成するものは、主に宗教と部屋の議論を断ち切ることに任されています。常に、今後もそうであるようなものがある場合は、個々の行に一意にマップすることで、主キーとして適切に機能します。その時点を過ぎると、他の考慮事項があります。
この最後の1つは、GUID、自己インクリメントの整数列などを使用するようにほとんどの人々を惹きつけるものです。住所、電話番号、姓名などに依存しているだけでは、それを切り取らないからです。私が考えることができる人についての唯一の不変はSSNですが、私はそれらが永遠にユニークであり続けることについて100％さえ確信していません。
うまくいけば、これはいくつかの明確さを追加するのに役立ちます...
私が主キーにアプローチする方法（そして私は最高だと感じています）は、「デフォルト」のアプローチを避けることです。これは、自動インクリメントする整数をたたいて、1日で呼び出すのではなく、問題を見て、「常に不変で変更されない列または列のグループはありますか？」と言います。答えが「はい」の場合、そのアプローチをとります。
わずかに関連性がありますが、小さな分類テーブル（基本的にコードでENUMを表すもの）があるときに最近始めたのは、主キーをchar（3）またはchar（4）にすることです。次に、これらの主キーをルックアップ値を表します。
たとえば、社内の販売代理店の見積もりシステムがあります。すべての見積品目に次のいずれかが割り当てられる「コストカテゴリ」があります...したがって、「tCostCategories」というタイプのルックアップテーブルがあり、主キーは「MTL」、「SVC」、「TRV」、「TAX」、 「ODC」。ルックアップテーブルの他の列には、コードの通常の英語の意味、「材料」、「サービス」、「旅行」、「税金」、「その他の直接費用」などの詳細が格納されます。
これはintよりも多くのスペースを使用しないため、本当に便利です。ソースデータを表示しているときに、値が何であるかを知るためにルックアップテーブルをリンクする必要はありません。たとえば、見積もり行は次のようになります。
1 PartNumber $ 40 MTL
2 OtherPartNumber $ 29.99 SVC
3 PartNumber2 $ 150 TRV
intを使用してカテゴリを表し、すべての行で1、2、3をリンクする方がはるかに簡単です。目の前にデータがあり、パフォーマンスはまったく影響を受けていないようです（私はそうではありません）本当にテスト済みです。）
本当の質問に関する限り...私はRowGUID uniqueidentifiersが好きです。私はこれについて100％ではありませんが、とにかくすべての行に内部RowGuidがあるわけではありませんか？その場合、RowGuidを使用すると、実際にはint（またはそのほかのこと）に比べてスペースが少なくて済みます。私が知っているのは、M $がGreatPlainsで使用するのに十分であれば、それで十分です。（カモにすべきか？）
GUIDを使用するもう1つの理由-階層データ構造を使用します。つまり、主キーが一致する「会社」という表と「ベンダー」という表があります。しかし、会社から「継承」するテーブル「メーカー」も持っています。ベンダーとメーカーに共通のフィールドはこれらのテーブルには表示されません-それらは会社に表示されます。この設定では、intの使用はGuidsよりもはるかに困難です。少なくとも、ID主キーは使用できません。
信頼できるときはいつでも、自然な鍵が好きです。主題の専門家に意味のあるキーを使用するために、パフォーマンスの価格を少しでも支払うことをいとわない。
エンティティを説明するテーブルの場合、人々が行う主題と同じ方法で個々のインスタンスを識別する単純な自然キーが必要です。主題にエンティティの1つに対する信頼できる識別子がない場合は、代理キーを使用します。
関係を説明するテーブルでは、複合キーを使用します。各コンポーネントは、関係に参加するエンティティを参照するため、エンティティテーブルの行を参照します。繰り返しになりますが、複合キーを使用した場合のパフォーマンスへの影響は通常最小限です。
他の人が指摘したように、「主キー」という用語は少し誤解を招きます。リレーショナルデータモデルでは、使用される用語は「候補キー」です。1つのテーブルに複数の候補キーが存在する可能性があります。論理的には、それぞれが他と同じくらい優れています。それらの1つを「プライマリ」として選択し、そのキーを介してすべての参照を作成することは、設計者ができる選択です。
Guids.period。
スケールアウトする必要がある場合、または別の方法で主キーを割り当てる必要がある場合、それらはあなたの友達になります。他のすべてのインデックスを追加できます。
私の声明を明確にするために更新します。
私はさまざまな種類のサイトに取り組んできました。小規模な単一サーバーから、複数のDBサーバーとWebサーバーでサポートされる大規模サーバーまで。確かに、自動インクリメントのintを主キーとするだけで問題がなかったはずのアプリがありました。しかし、それらは私のやり方のモデルに適合しません。
GUIDを使用する場合は、どこにでもIDを生成できます。リモートサーバー、Webアプリ、データベース自体、またはマルチマスターの状況では複数のデータベース内で生成される可能性があります。
一方、自動インクリメントされたINTは、プライマリデータベース内でのみ安全に生成できます。繰り返しになりますが、この1つのバッキングDBサーバーに密接に結び付けられ、スケールアウトが気になるものではないアプリケーションがある場合、これは問題ありません。
確かに、GUIDを使用すると、毎晩再インデックス処理を行う必要があります。ただし、自動インクリメントINT以外を使用している場合は、とにかくそれを行う必要があります。INTをプライマリとして使用しても、断片化に対処するために再生成が必要な他のインデックスがある可能性があります。したがって、GUIDを使用しても、それらのタスクは関係なく実行する必要があるため、別の問題が正確に追加されるわけではありません。
そこにある大きなアプリを見ると、何か重要なことがわかります。それらはすべて、Base64でエンコードされたGUIDをキーとして使用しています。この理由は単純です。GUIDを使用すると、簡単にスケールアウトできますが、INTをスケールアウトしようとすると、多くのフープが飛び越えてしまう可能性があります。
最新のアプリは、約1か月続く大量の挿入の期間を通過します。その後、90％以上のクエリがすべてレポート用に選択されています。容量を増やすために、この大きな挿入期間中に追加のDBサーバーを起動できます。後でそれらをレポート用に単一のDBに簡単にマージします。INTでそれを試みるのは絶対的な悪夢です。
率直に言って、データベースをクラスター化したり、レプリケーションをセットアップしたりするときはいつでも、DBサーバーはとにかくテーブルにGUIDがあることを要求します。したがって、システムを拡張する必要があると思われる場合は、適切なシステムを選択してください。
これは、あなたが気づいたかどうかにかかわらず、複雑なテーマです。このStackOverflow FAQのセクションに該当する場合があります。
ここではどんな質問をしてはいけませんか？
主観的、議論的、または長期にわたる議論を必要とする質問をしないでください。質問に答えられる場所です！
これは何年もの間議論されてきました、そして何年もの間議論され続けます。私が見たコンセンサスの唯一のヒントは、OOガイ（GUIDが唯一の方法です！）、データモデラー（自然キーが唯一の方法です！）またはパフォーマンス指向のDBA（INTが唯一の方法です！）。