常に自動インクリメント整数のプライマリキーを持つことは良い習慣ですか？

私のデータベースでは、id特定の行を一意に検索できるように、作成するすべてのテーブルの名前に整数の主キーを自動的にインクリメントするという習慣になりがちです。

これは悪い考えと考えられますか？この方法で行うことには欠点がありますか？場合によっては、一意の識別子id, profile_id, subscriptionsがどこにあるか、テーブルの外部へのリンクなどの複数のインデックスがあります。idprofile_ididProfile

または、そのようなフィールドを追加したくないシナリオはありますか？

一意の行識別子を保証することは決して悪い考えではありません。決して言ってはいけないことだと思いますが、圧倒的多数の時間を使ってみましょう。

理論的な潜在的な欠点には、維持するための追加のインデックスと使用される追加のストレージスペースが含まれます。それを使用しない理由はこれだけでは十分ではありません。

以前のすべての答えに同意しません。すべてのテーブルに自動インクリメントフィールドを追加することはお勧めできませんが、多くの理由があります。

明らかなキーがないテーブルがある場合、自動インクリメントフィールドは良い考えのようです。結局のところ、あなたはしたくないselect * from blog where body = '[10000 character string]'。むしろあなたがしたいselect * from blog where id = 42。これらの場合のほとんどで、本当に必要なのは一意の識別子であると主張します。連続した一意の識別子ではありません。代わりに、普遍的に一意の識別子を使用する必要があります。

ほとんどのデータベースには、ランダムな一意の識別子を生成する関数があります（uuidmysql、postgres newid、mssql）。これらを使用すると、異なるマシン上の複数のデータベースにデータをいつでも生成でき、それらの間のネットワーク接続はなく、競合なしでデータをマージできます。これにより、たとえばマイクロサービスなどを使用して、複数のサーバーやデータセンターをより簡単にセットアップできます。

また、これにより、攻撃者がアクセスすべきでないページのURLを推測することを防ぎます。がある場合は、https://example.com/user/1263おそらく https://example.com/user/1262もあります。これにより、ユーザープロファイルページでセキュリティの悪用を自動化できます。

uuidカラムが役に立たなかったり、有害でさえある場合も多くあります。ソーシャルネットワークがあるとします。usersテーブルとテーブルがありfriendsます。friendsテーブルには、2つのユーザーID列と1つの自動インクリメントフィールドが含まれます。の3友達になりたい5ので3,5、データベースに挿入します。データベースは、自動インクリメントIDとstoresを追加します1,3,5。どういうわけか、ユーザー3は「友達を追加」ボタンをもう一度クリックします。3,5データベースに再度挿入すると、データベースは自動インクリメントIDを追加してinsertを挿入します2,3,5。しかし、今3、5お互いに二度友達です！これはスペースの無駄です。考えてみると、自動インクリメント列も無駄です。あなたがどうかを確認する必要があるすべてaとbこれらの2つの値を持つ行を選択することです。これらは合わせて、一意の行識別子です。（おそらく、重複排除のためにいくつかのロジックを作成する必要が3,5あり5,3ます。）

url-shortenerを作成するときのように、シーケンシャルIDが有用な場合もありますが、ほとんどの場合（URL短縮機能を使用する場合でも）ランダムに生成された一意のIDを代わりに使用したいです。

TL; DR：各行を一意に識別する方法がまだない場合は、自動インクリメントの代わりにUUIDを使用します。

Autoincementalキーには主に利点があります。

ただし、考えられる欠点は次のとおりです。

• ビジネスキーがある場合は、ビジネスルールを適用するために、その列にも一意のインデックスを追加する必要があります。
• 2つのデータベース間でデータを転送する場合、特にデータが複数のテーブル（マスター/詳細）にある場合、データベース間でシーケンスが同期されないため、簡単ではありません。最初に、を使用して等価テーブルを作成する必要があります起点データベースのどのIDがターゲットデータベースのどのIDに対応するかを知るための一致としてのビジネスキー。ただし、分離されたテーブルとの間でデータを転送する場合、これは問題になりません。
• 多くの企業には、アドホック、グラフィカル、ポイントアンドクリック、ドラッグアンドドロップのレポートツールがあります。自動増分IDは無意味であるため、このタイプのユーザーは、「アプリ」以外のデータを理解するのが難しいと感じるでしょう。
• 誤ってビジネスキーを変更した場合、その行を回復することはできなくなる可能性があります。これは、人間がそれを識別するための何かをもう持っていないためです。これはBitCoinプラットフォームで一度障害を引き起こしました。
• 一部の設計者は、PKを2つの外部IDで単純に構成する必要がある場合に、2つのテーブル間の結合テーブルにIDを追加します。明らかに、結合テーブルが3つ以上のテーブルの間にある場合、自動増分IDは意味をなしますが、FKの組み合わせに適用してビジネスルールを適用する場合は、一意のキーを追加する必要があります。

ここに、代理キーの欠点に関するウィキペディアの記事セクションがあります。

反対に、いいえ、常に数値のAutoInc PKを持っている必要はありません。

データを慎重に分析すると、多くの場合、データ内の自然キーを識別します。これは、データがビジネスにとって本質的な意味を持つ場合によくあります。PKは、システムの属性を記述するためにビジネスユーザーが第二言語として利用する古代のシステムの成果物である場合があります。たとえば、車両管理システムの「車両」テーブルの主キーとして使用される車両VIN番号を見てきました。

独自の識別子を既に持っている場合は、それが使用されている場合、それが発生しました。2番目の無意味な主キーを作成しないでください。無駄であり、エラーを引き起こす可能性があります。

AutoInc PKを使用して、ポリシー番号などの顧客にとって意味のある値を生成できる場合があります。開始値を適切な値に設定し、先行ゼロなどに関するビジネスルールを適用します。これはおそらく「両方の世界のベスト」アプローチです。

比較的静的な値が少数ある場合は、システムユーザーにとって意味のある値を使用します。保険の「保険種別」コンテキストでL、H、CがLife、Car、Homeを表すL、C、Hを使用できる場合、またはVINの例に戻って「TO 「トヨタの？Toyataのすべての車には、「TO」で始まるVINがあります。ユーザーが覚えておくべきことが1つ減り、プログラミングやユーザーエラーが発生する可能性が低くなります。書くこと、そしておそらくより速く生成すること。

これのさらなる開発はおそらく「あまりにも大きな橋」であり、一般的にはお勧めしませんが、完全を期すためにこれを含めています。つまり、説明を主キーとして使用します。急速に変化するデータの場合、これは憎悪です。以下のための非常に報告された静的データのすべての時間、そうでないかもしれません。言及するだけで、可能性としてそこに座っています。

私はAutoInc PKを使用しています。頭をかき回し、より良い選択肢を最初に探します。データベース設計の技術は、意味のあるものを作成しており、すぐに問い合わせることができます。結合が多すぎると、これが妨げられます。

編集自動生成PKを必要としないもう1つの重要なケースは、他の2つのテーブルの共通部分を表すテーブルのケースです。車の類推に固執するために、A Carには0..nのアクセサリーがあり、各アクセサリーは多くの車にあります。そのため、これを表すには、CarおよびAccessoryからのPKおよびリンクの日付などに関するその他の関連情報を含むCar_Accessoryテーブルを作成します。

（通常）必要ないのは、このテーブルのAutoInc PKです。「この車にはどのアクセサリーが入っているか教えてください」、または「この車にはどのアクセサリーがあるのか​​教えてください」というアクセサリーからのみアクセスできます。

多くのテーブルにはすでに自然な一意のIDがあります。これらのテーブルに別の一意のID列（自動インクリメントまたはその他）を追加しないでください。代わりに自然な一意のIDを使用してください。別の一意のIDを追加する場合、基本的にデータに冗長性（重複または依存関係）があります。これは、正規化の原則に反します。1つの一意のIDは、正確性のために他のIDに依存しています。これは、彼らがで同期して完全に保たれなければならないことを意味し、すべての回ですべてのシステムこれらの行を管理します。データの整合性におけるもう1つの脆弱性は、長期にわたって管理および検証する必要がないことです。

最近のほとんどのテーブルでは、一意のid列を追加することでパフォーマンスが大幅に向上する必要はありません（パフォーマンスが低下することもあります）。ITの一般的なルールとして、ペストのような冗長性は避けてください！それがあなたに提案されるどこでもそれに抵抗しなさい。嫌悪感です。そして、引用に注意してください。すべてをできるだけシンプルにする必要がありますが、シンプルではありません。自然なIDが整頓されていないように見えても、1つで十分な2つの一意のIDを持たないでください。

大規模なシステムでは、IDは一貫性を高めるため、ほとんどどこでも使用できます。このコンテキストでは、個々の主キーは推奨されません。最終的には高価です（理由をお読みください）。

すべてのルールには例外があるため、エクスポート/インポートに使用されるステージングテーブル、および同様の一方向テーブルまたは一時テーブルで整数の自動インクリメントIDを必要としない場合があります。また、分散システムではIDではなくGUIDを好むでしょう。

ここでの多くの回答は、既存の一意のキーを使用する必要があることを示唆しています。150文字の場合でも？そうは思いません。

今私の主なポイント：

自動インクリメント整数IDの反対者は、最大20個のテーブルを持つ小さなデータベースについて話しているようです。そこで、各テーブルに対して個別のアプローチを行う余裕があります。

しかし、400以上のテーブルを持つERPがあれば、整数の自動インクリメントIDをどこにでも持つことができます（上記の場合を除く）。他の一意のフィールドが存在し、一意性が確保されている場合でも、それらに依存することはありません。

• 普遍的な時間節約、労力節約、覚えやすいコンベンションの恩恵を受けます。
• ほとんどの場合JOIN、キーが何であるかをチェックする必要なしにテーブルを作成します。
• 整数の自動インクリメント列で動作するユニバーサルコードルーチンを使用できます。
• 既存のテーブルのIDを参照するだけで、以前は予見されなかった新しいテーブルまたはユーザープラグインでシステムを拡張できます。それらは最初からすでに存在し、追加する費用はかかりません。

大規模なシステムでは、これらの個々の主キーの小さな利点を無視し、ほとんどの場合、整数の自動インクリメントIDを一貫して使用する価値があります。既存の一意のフィールドを主キーとして使用すると、レコードごとに数バイト節約できますが、追加のストレージまたはインデックス作成時間は、今日のデータベースエンジンでは問題になりません。実際、開発者/保守者の無駄な時間に多くのお金とリソースを失っています。今日のソフトウェアは、プログラマーの時間と労力に合わせて最適化する必要があります。一貫性のあるIDを使用するアプローチは、はるかに優れています。

余計な設計はお勧めできません。つまり、不要な場合は常に主キーを自動インクリメントすることはお勧めできません。

不要な例を見てみましょう。

記事用のテーブルがあります。これには、int主キーid、およびという名前のvarchar列がありtitleます。

また、記事のカテゴリでいっぱいのテーブルがありますid。int主キーvarchar nameです。

Articlesテーブルの1行にはid、5とtitle 「ガチョウをバターで調理する方法」があります。その記事をCategoriesテーブルの次の行にリンクします： "Fowl"（id：20）、 "Goose"（id：12）、 "Cooking"（id：2）、 "Butter"（id：9） 。

これで、記事とカテゴリの2つのテーブルができました。2つの間の関係はどのように作成しますか？

id（主キー）、article_id（外部キー）、category_id（外部キー）の3つの列を持つテーブルを作成できます。しかし、今は次のようなものがあります：

| id | a_id | c_id |
| 1 | 5 | 20 |
| 2 | 5 | 12 |
| 3 | 5 | 2 |

より良い解決策は、2つの列で構成される主キーを持つことです。

| a_id | c_id |
| 5 | 20 |
| 5 | 12 |
| 5 | 2 |

これは以下を行うことで実現できます。

create table articles_categories (
  article_id bigint,
  category_id bigint,
  primary key (article_id, category_id)
) engine=InnoDB;

自動インクリメント整数を使用しないもう1つの理由は、主キーにUUIDを使用している場合です。

UUIDは定義上一意であり、一意の整数を使用した場合と同じことを実現します。また、整数に対して独自の追加の利点（および短所）もあります。たとえば、UUIDを使用すると、参照している一意の文字列が特定のデータレコードを指していることがわかります。これは、1つの中央データベースがない場合、またはアプリケーションがデータレコードをオフラインで作成する機能を備えている場合（後でデータベースにアップロードする場合）に便利です。

最終的に、主キーを物事として考える必要はありません。それらを実行する機能と考える必要があります。なぜ主キーが必要なのですか？将来変更されないフィールドを使用して、テーブルから特定のデータセットを一意に識別できるようにするため。idこれを行うために呼び出される特定の列が必要ですか、それとも他の（不変の）データに基づいてこの一意の識別を行うことができますか？

または、そのようなフィールドを追加したくないシナリオはありますか？

承知しました。

まず第一に、自動インクリメントを持たないデータベースがあります（たとえば、Oracleは確かに周りの最小の競合の1つではありません）。これは、誰もがそれらを好むまたは必要とするわけではないことを示す最初の兆候です。

さらに重要なのは、IDが実際に何を考えている -それはあなたのデータの主キーです。別の主キーを持つテーブルがある場合、IDは必要ありません。たとえば、テーブル(EMPLOYEE_ID, TEAM_ID)（各従業員が複数のチームに同時に参加できる場合）には、これら2つのIDで構成される明確に定義された主キーがあります。IDこのテーブルの主キーでもある自動インクリメント列を追加しても、まったく意味がありません。これで、2つの主キーを持ち歩くことができます。「主キー」の最初の単語から、本当に1つだけが必要であるというヒントが得られます。

「長命」データ（ビットフィールドを設定して「論理的に削除」されたとしても、一度挿入して無期限に保持する予定のレコード）の新しいテーブルを定義するときは、通常「ID」列（自動更新整数）を使用します）。

使用したくないときに考えられる状況がいくつかあります。そのほとんどは、DBの1つのインスタンス上の1つのテーブルが新しいID値の信頼できるソースにならないシナリオになります。

• 潜在的な攻撃者にとってインクリメンタルIDが多すぎる情報になる場合。「公共向け」データサービスにID列を使用すると、「ドイツ戦車問題」に対して脆弱になります。レコードID 10234が存在する場合、レコード10233、10232などが存在し、少なくともレコード10001に戻っていることがわかります。その後、レコード1001、101、1を確認して、ID列がどこから始まったのかを簡単に確認できます。主にランダムなデータで構成されるV4 GUIDは、このインクリメンタル動作を設計上破壊します。そのため、1つのGUIDが存在するからといって、GUIDのバイトをインクリメントまたはデクリメントすることで作成されたGUIDは必ずしも存在しないため、攻撃者が意図したサービスを使用するのが難しくなりますダンプツールとしての単一レコードの取得用。アクセスをより制限できるセキュリティ対策は他にもありますが、これは役立ちます。
• M：M相互参照テーブル。これは一種のギミーですが、私はそれを以前に見ました。データベース内の2つのテーブル間に多対多の関係がある場合、適切なソリューションは、各テーブルのPKを参照する外部キー列を含む相互参照テーブルです。このテーブルのPKは、組み込みインデックスの動作を取得し、参照の一意性を確保するために、実質的に常に2つの外部キーの複合キーである必要があります。
• このテーブルで大量の挿入と削除を大量に計画する場合。おそらく、ID列の最大の欠点は、元のテーブルのキー値を維持したい別のテーブルまたはクエリから行を挿入するときに経験しなければならない余分な問題です。「ID挿入」をオンにする必要があります（DBMSで行われます）。次に、挿入するキーが一意であることを手動で確認し、インポートが完了したら、IDカウンターをテーブルのメタデータを存在する最大値まで。このテーブルでこの操作が頻繁に発生する場合は、別のPKスキームを検討してください。
• 分散テーブル用。ID列は、単一インスタンスデータベース、フェールオーバーペア、および特定の時点で1つのデータベースインスタンスがデータスキーマ全体に対する唯一の権限であるその他のシナリオに最適です。ただし、1台のコンピューターで十分な速度を維持しながら移動できるのは非常に大きいだけです。レプリケーションまたはトランザクションログ配布により、追加の読み取り専用コピーを取得できますが、そのソリューションの規模にも制限があります。遅かれ早かれ、データの挿入を処理し、相互に同期する2つ以上のサーバーインスタンスが必要になります。ほとんどのDBMSは、インスタンス固有の識別子として生成するGUIDの一部を使用するように事前に構成されているため、増分ではなくGUIDフィールドが必要になります。その後、残りの識別子をランダムに生成します。または増分。どちらの場合にも、
• DBの複数のテーブルに一意性を適用する必要がある場合。会計システムでは、たとえば、総勘定元帳（これまでに発生したすべてのアカウントのクレジットまたはデビットごとに行があるため、非常にすばやく大きくなります）をそれぞれ1暦月/月を表すテーブルのシーケンスとして管理することが一般的です年。その後、ビューを作成して、レポート用にそれらを一緒にフックできます。論理的には、これはすべて1つの非常に大きなテーブルですが、それを切り詰めることで、DBのメンテナンスジョブが簡単になります。ただし、重複キーで終わることなく、複数のテーブルへの挿入を管理する方法の問題を提示します（最後のトランザクションを閉じながら、翌月にトランザクションのロギングを開始できるようにします）。繰り返しになりますが、DBMSはこれらを真にユニークな方法で生成するように設計されているため、ID整数列ではなくGUIDが最適なソリューションです。

願わくば述べたように、これらの状況でID列を使用できる回避策がありますが、ほとんどの場合、ID整数列からGUIDへのアップグレードはより簡単で、問題をより完全に解決します。

自動インクリメント（ID）主キーは、データベースおよびそのデータベースの直接のクライアントのコンテキストの外では意味がないことに注意することを除いて、良いアイデアです。たとえば、データの一部を別のデータベースに転送して保存した後、両方のデータベーステーブルに異なるデータを書き込むと、IDが分岐します。つまり、1つのデータベースのIDが42のデータは必ずしもデータと一致しませんもう一方のIDは42です。

これを考えると、データベースの外部で行を一意に識別できる必要がある場合（および頻繁に識別される場合）、この目的のために別のキーが必要です。慎重に選択されたビジネスキーでもかまいませんが、多くの場合、一意性を保証するために必要な多数の列の位置になります。別の手法は、ID列を自動インクリメントクラスター化プライマリキーとして使用し、別のuniqueidentifier（guid）列を非クラスター化ユニークキーとして使用して、行が世界中のどこに存在するかを一意に識別することです。この場合に自動インクリメントキーがまだある理由は、GUIDに同じ操作を行うよりも、自動インクリメントキーをクラスター化してインデックス化する方が効率的だからです。

自動インクリメントキーが必要ない場合の1つのケースは、主キーが他の2つのテーブルのId列の複合である多対多テーブルです（ここでも自動インクリメントキーを使用できますが、その要点がわからない）。

もう1つの質問は、自動増分キーのデータ型です。Int32を使用すると、値の範囲は大きくなりますが、比較的制限されます。個人的には、実際には値の不足を心配する必要がないように、Idにbigint列を頻繁に使用します。

他の人々がインクリメントする主キーを主張しているように、私はGUIDの1つを作成します：

• 一意であることが保証されています
• アプリケーションのデータを取得するために、データベースへのアクセスを1回減らすことができます。（たとえば、タイプテーブルの場合、GUIDをアプリケーションに保存し、それを使用してレコードを取得できます。IDを使用する場合は、名前でデータベースをクエリする必要があり、これを実行してPKを取得する多くのアプリケーションを見てきました後で再度クエリを実行して詳細を取得します）。
• データを隠すのに便利です。www.domain.com/Article/2では2つの記事しかありませんが、www.domain.com / article / b08a91c5-67fc-449f-8a50-ffdf2403444aでは何もわかりません。
• 異なるデータベースのレコードを簡単にマージできます。
• MSFTは、IDにGUIDSを使用します。

編集：ポイントの複製

優れた設計の原則として、すべてのテーブルには、行を一意に識別する信頼できる方法が必要です。それが主キーの目的ですが、主キーの存在が常に必要なわけではありません。主キーをすべてのテーブルに追加することは、一意の行識別を提供するため、悪い習慣ではありませんが、不要な場合があります。

2つ以上のテーブルの行間の信頼できる関係を維持するには、外部キーを介して行う必要があります。したがって、少なくともいくつかのテーブルで主キーが必要になります。すべてのテーブルに主キーを追加すると、新しいテーブルまたはリレーションシップを既存のデータに追加するときに、データベース設計を簡単に拡張できます。事前の計画は常に良いことです。

基本原則（おそらくハードルール）として、主キーの値は、その行の存続期間を通じて決して変更されるべきではありません。行内のビジネスデータはその存続期間中に変更される可能性があると想定するのが賢明です。そのため、ビジネスデータは主キーの適切な候補ではありません。これが、自動インクリメント整数のような抽象的な何かがしばしば良いアイデアである理由です。ただし、自動インクリメントされた整数には制限があります。

データがデータベース内でのみ有効である場合、自動インクリメントされた整数で十分です。しかし、他の回答で述べたように、データの共有、同期、またはデータベース外での生活を希望する場合、自動インクリメントされた整数は主キーを貧弱にします。より良い選択は、guid（別名uuid "universally unique id"）です。

質問と回答の多くは、各テーブルのすべての自然キーがデータベースの論理スキーマにのみ存在し、各テーブルのすべての代理キーがデータベースの物理スキーマにのみ存在するという重要なポイントを見逃しています。他の回答では、サロゲートキーが適切に使用される理由とタイミングを説明せずに、整数とGUIDサロゲートキーの相対的な利点のみを説明します。

BTW：不明確で不正確な用語の主キーの使用を避けましょう。これは、リレーショナルモデルに最初に（無意味に）採用され、その後さまざまなRDBMSベンダーによって物理ドメインに再度採用された、リレーショナル前データモデルの成果物です。その使用は、セマンティクスを混乱させるだけです。

リレーショナルモデルから、データベースの論理スキーマを最初の標準形式にするために、すべてのテーブルには、テーブルの各行を一意に識別する、ユーザーが表示できるナチュラルキーと呼ばれるフィールドのセットが必要であることに注意してください。ほとんどの場合、そのような自然なキーは容易に識別されますが、タイブレーカーフィールドとして、またはその他の方法で、キーを構築する必要がある場合があります。ただし、このような構築されたキーは常にユーザーに表示されるため、常にデータベースの論理スキーマに存在します。

対照的に、テーブルの代理キーはデータベースの物理スキーマに純粋に存在します（したがって、セキュリティ上の理由とデータベースの整合性の維持の両方のために、データベースユーザーには常に完全に見えないようにする必要があります）。代理キーを導入する唯一の理由は、DBの物理的なメンテナンスと使用におけるパフォーマンスの問題に対処することです。結合、複製、データ用の複数のハードウェアソース、その他のいずれかです。

代理キーを導入する唯一の理由はパフォーマンスであるため、パフォーマンスを向上させたいと考えています。目前のパフォーマンスの問題が結合である場合は、サロゲートキーをできる限り狭くする必要があります（ハードウェアを邪魔することなく、通常、短い整数とバイトは出力されません）。結合のパフォーマンスは最小のインデックスの高さに依存するため、4バイト整数は自然な解決策です。パフォーマンスの問題が挿入率である場合、4バイト整数も自然な解決策になる可能性があります（RDBMSの内部によって異なります）。テーブルのパフォーマンスの問題がレプリケーションまたは他のサロゲートキーテクノロジーよりも複数のデータソースである場合、GUIDまたは2つの部分からなるキー（ホストID +整数）の方が適している可能性があります。私は個人的にGUIDのお気に入りではありませんが、便利です。

要約すると、すべてのテーブルが（任意のタイプの）代理キーを必要とするわけではありません。これらは、検討中のテーブルのパフォーマンスに必要と考えられる場合にのみ使用してください。どの一般的な代理キーテクノロジーを選択するかに関係なく、選択を行う前にテーブルの実際のニーズについて慎重に検討してください。テーブルのサロゲートキーテクノロジーの選択を変更すると、手間がかかります。テーブルの主要なパフォーマンスメトリックを文書化して、後継者が選択内容を理解できるようにします。

特殊なケース

1. ビジネス要件が監査（またはその他）の目的でトランザクションの連番を要求する場合、そのフィールドは代理キーではありません。それは自然なキーです（追加要件があります）。ドキュメントから、自動インクリメント整数はサロゲートキーのみを生成するので、それを生成する別のメカニズムを見つけてください。当然、何らかのモニターが必要になります。トランザクションを複数のサイトから調達している場合、モニターの指定ホストサイトであるため、1つのサイトが特別になります。

2. テーブルが約100行を超えない場合、インデックスの高さは関係ありません。すべてのアクセスはテーブルスキャンによるものです。ただし、長い文字列での文字列比較は、4バイト整数の比較よりもはるかに高く、GUIDの比較よりも高くなります。

3. char（4）コードフィールドでキー付けされたコード値のテーブルは、4バイト整数を持つものと同じようにパフォーマンスが高くなければなりません。私はこれの証拠を持っていませんが、私は頻繁に仮定を使用し、それを破る理由がありませんでした。

良い習慣ではないだけでなく、実際には、ビル・カーウィンのSQL Antipatterns本でアンチパターンとして説明されています。

すべてのテーブルが擬似キー（モデルのセマンティックな値を持つものではなく、任意の値を持つ主キー）を必要とするわけではなく、常に呼び出す理由はありませんid。

これはかなり普遍的です-そうでなければ、キーが実際に一意であることを検証する必要があります。これは、他のすべてのキーを調べることによって行われます...時間がかかります。レコード番号がキーオーバーフロー値に近づくにつれて、増分キーを使用するとコストがかかります。

私は通常、ポインタをより明確なフィールド名ref_{table}または類似のアイデアにします。

外部的にレコードを指す必要がない場合は、IDは必要ありません。

いつもやるべきだとは言いません。ここには一意のキーのないテーブルがありますが、それは必要ありません。監査ログです。更新は決して行われず、クエリはログに記録されているものに対するすべての変更を返しますが、それは合理的な方法で行うことができる最良のものであり、人間が不法な変更を定義する必要があります。（コードができれば、そもそもそれを許可していなかったでしょう！）

主キーの自動インクリメントカウンターはお勧めできません。これは、データを挿入する前に、データベースに戻って次のキーを見つけ、1ずつ増やす必要があるためです。

そうは言っても、データベースが主キーに提供できるものであれば、アプリケーションの一部としてではなく、一般的に使用します。

データベースにネイティブに提供させることにより、キーが必要なものに対して一意であることを保証できます。

もちろん、すべてのデータベースがサポートしているわけではありません。その場合、私は通常、キーバケットを格納するテーブルを使用し、アプリケーションで管理される高範囲と低範囲を使用します。これは、10000の範囲の番号を取得し、アプリケーションインスタンスで自動的にインクリメントするため、私が見つける最もパフォーマンスの高いソリューションです。別のアプリケーションインスタンスは、処理する別の数のバケットを選択できます。64ビット長など、十分に大きなプライマリキープリミティブが必要です。

UUIDを主キーとして使用しないのは、それらを構築して格納するコストが、長い値を1ずつ増やすよりもはるかに高いためです。UUIDは、理論的には重複が発生する可能性があるという点で、誕生日のパラドックスを扱っています。