私は、データベースと、その仕組みの背後にある理論についてはあまり詳しくありません。主キーに文字列を使用するのは整数よりもパフォーマンスの観点（挿入/更新/クエリ）の面で遅いですか？
私は、データベースと、その仕組みの背後にある理論についてはあまり詳しくありません。主キーに文字列を使用するのは整数よりもパフォーマンスの観点（挿入/更新/クエリ）の面で遅いですか？
回答:
技術的にはそうですが、文字列が主キーであることが理にかなっている場合は、おそらくそれを使用する必要があります。これはすべて、作成するテーブルのサイズと、主キーになる文字列の長さに依存します（文字列が長いほど、==比較が難しくなります）。数百万の行があるテーブルには必ずしも文字列を使用するわけではありませんが、小さいテーブルで文字列を使用することで得られるパフォーマンスの低下は、データに関して何も意味しません。
文字列を主キーとして使用する場合のもう1つの問題は、インデックスが常に順番に配置されるため、新しいキーが作成されると、インデックスの順序を変更する必要がある順序で新しいキーを作成する必要があるということです...整数の場合、新しいキーはインデックスの最後に追加されます。
クラスター化インデックスを持つテーブルに挿入しても、シーケンスの途中で挿入が行われると、インデックスが書き換えられることはありません。データを構成するページが書き換えられることはありません。行が移動するページにスペースがある場合は、そのページに配置されます。1ページが再フォーマットされ、行がページの適切な場所に配置されます。ページがいっぱいになると、ページ分割が行われ、ページの行の半分が1つのページに移動し、残りの半分が他のページに移動します。次に、ページは、クラスター化インデックスを持つテーブルデータを構成するページのリンクリストに再リンクされます。せいぜい2ページのデータベースを作成するだけです。
文字列は結合では低速であり、実際には（たとえそうであるはずであっても）実際に一意であることは非常にまれです。唯一の利点は、名前を取得するためだけにプライマリテーブルに結合している場合に、結合の数を減らすことができることです。ただし、文字列は変更されることも多いため、会社名が変更されたり、人が結婚したりすると、関連するすべてのレコードを修正する必要があるという問題が生じます。これはパフォーマンスに大きな影響を与える可能性があり、何らかの方法で関連付ける必要があるすべてのテーブルが関連付けられていない場合（これは思ったよりも頻繁に発生します）、データの不一致も発生する可能性があります。レコードの存続期間を通じて変更されない整数は、パフォーマンスの観点からだけでなく、データの整合性の観点からもはるかに安全な選択です。自然キーは通常、データのメンテナンスにはあまり適していません。
また、両方の世界の最良の点は、自動インクリメントキー（または一部の特殊なケースではGUID）をPKとして使用し、固有キーに固有のインデックスを配置することです。より高速な結合が得られ、重複したレコードは得られません。会社名が変更されたため、100万の子レコードを更新する必要はありません。
変数が多すぎます。これは、テーブルのサイズ、インデックス、文字列キードメインの性質によって異なります...
通常、整数の方が高速です。しかし、その差は気になるほど大きいでしょうか？言うのが難しい。
また、弦を選ぶ動機は？多くの場合、数値の自動インクリメントキーも非常に簡単です。それは意味論ですか？便利？レプリケーション/切断の懸念？ここでの答えは、オプションを制限する可能性があります。これは、忘れている3番目の「ハイブリッド」オプション、Guidsも思い出します。
データが説明する主題に一致し、データの使用目的によく適合するシンプルで健全な設計が得られるまで、パフォーマンスについて心配する必要はありません。その後、パフォーマンスの問題が発生した場合は、システムを調整することで対処できます。
この場合、ほとんどの場合、文字列を自然な主キーとして使用することをお勧めします（信頼できる場合）。文字列であっても心配しないでください。文字列が適度に短い限り、最大約25文字です。パフォーマンスの点で大きな代償を払うことはありません。
データ入力担当者または自動データソースは、想定される自然キーの値を常に提供しますか、それとも省略されることがありますか？入力データに時々間違っていますか？もしそうなら、エラーはどのように検出され、修正されますか？
クエリを指定するプログラマーやインタラクティブユーザーは、自然なキーを使用して必要なものを取得できますか？
自然キーを信頼できない場合は、代理を作成してください。サロゲートを発明する場合、整数を発明することもできます。次に、サロゲートをユーザーコミュニティから隠すかどうかについて心配する必要があります。代理キーを隠さなかった一部の開発者は、それを後悔するようになりました。
はい。ただし、何百万もの行があると予想される場合を除いて、文字列ベースのキーを使用しないほうが遅いため、通常は「時期尚早の最適化」です。結局のところ、文字列は大きな数字として保存されますが、数字キーは通常、小さな数字として保存されます。
ただし、注意が必要なことの1つは、任意のキーにクラスター化されたインデックスがあり、インデックス内で連続していない挿入を多数実行している場合です。書き込まれるすべての行は、インデックスを書き換えます。バッチ挿入を実行している場合、これによりプロセスが本当に遅くなる可能性があります。
文字列を主キーとして持つ理由は何ですか？
主キーを自動インクリメント整数フィールドに設定し、文字列フィールドにインデックスを設定します。
そうすれば、テーブルで検索を行う場合は比較的高速になり、すべての結合と通常のルックアップは速度に影響されません。
インデックスが作成される文字列フィールドの量を制御することもできます。つまり、「最初の5文字だけをインデックスに登録する」と言えば、それで十分だと言えます。または、データが比較的類似している場合は、フィールド全体にインデックスを付けることができます。
パフォーマンスの観点から-はいstring（PK）は、PK ---> Primary Keyであるinteger（PK）を使用して達成されるパフォーマンスと比較すると、パフォーマンスを低下させます。
要件の観点から-これはあなたの質問の一部ではありませんが、私はまだ言及したいと思います。さまざまなテーブルにまたがる巨大なデータを処理する場合、通常、特定のテーブルに設定できる可能性のあるキーのセットを探します。これは主に多くのテーブルがあり、ほとんどすべてのテーブルまたは一部のテーブルが何らかのリレーション（外部キーの概念）を介して他のテーブルに関連付けられるためです。したがって、整数を主キーとして常に選択できるわけではありません。3、4、または5つの属性の組み合わせをそのテーブルの主キーとして使用します。そしてこれらのキーは、レコードを他のテーブルと関連付けるときに外部キーとして使用できます。これにより、必要に応じて、さまざまなテーブル間でレコードを関連付けることができます。
したがって、最適な使用法-1または2の整数と1または2の文字列属性の組み合わせを常に作成しますが、これも必要な場合のみです。
デフォルトでは、ASPNetUserIdsは128文字の文字列で、パフォーマンスは問題ありません。
キーが場合HASテーブル内で一意であるために、それはキーでなければなりません。これが理由です。
プライマリ文字列キー=正しいDB関係、1つの文字列キー（プライマリ）、および1つの文字列インデックス（プライマリ）。
他のオプションは、典型的なint型のキーですが、文字列があればHAS一意であることが、あなたはおそらくまだ検証するための理由はノンストップのクエリのインデックスを追加したり、そのユニークなことを確認する必要があります。
したがって、int IDキーを使用する= Incorrect DB Relationships、1 int key（Primary）、1 int index（Primary）、おそらく一意の文字列Index、および手動で同じ文字列を検証する必要がない（sql checkのようなもの） ）。
主キーの列の上にint型を使用して、より良いパフォーマンスを得るためには、文字列のときHAS一意であること、それは非常に奇妙な状況でなければならないであろう。私は常に文字列キーを使用することを好みました。あなたがされるまで、親指の良いルールとして、データベースを非正規化していないNEEDに。