5

私の Web アプリケーションには、ルート ユーザー、システム管理者、顧客、請負業者など、さまざまなタイプのユーザーがいます。列「ユーザー名」、「パスワード」、「役割」で、役割は前述の役割の 1 つです。たとえば、顧客固有の属性を格納するための「Customer」というテーブルも作成します。

これが私の質問です。すべてのユーザー名は一意であるため、ユーザー名を User テーブルの主キーとして使用できます。ただし、「ユーザー ID」列を作成し、ユーザー名列ではなくそれを PK として使用する方が理にかなっていますか? このユーザー PK を外部キーとして使用するテーブルは他にもたくさんありますが、パフォーマンスの観点からは、ユーザー名のテキスト文字列よりもユーザー ID を比較する方が高速になると思います。

ご回答ありがとうございます。

4

3 に答える 3

8

これは、古い自然対代理キーの議論です。

一言で言えば、カットアンドドライではなく、競合する利益の間でバランスを取る必要があります。

  1. キーを更新する必要があると予想される場合は、サロゲート (更新の必要がない) を使用して、ON UPDATE CASCADE を回避します。
  2. キーをルックアップする必要があるが、他の列をルックアップする必要がない場合は、自然キーを使用して JOIN を完全に回避します。ただし、キー以外のルックアップが必要な場合は、サロゲートを使用して、FK と付随するインデックスをよりスリムで効率的にします。
  3. 自然キーでの範囲スキャンを想定していますか? はいの場合は、クラスター化します。ただし、セカンダリ インデックスは、クラスター化されたテーブルではコストがかかる可能性があり、代理キーと競合します。
  4. あなたのテーブルはとても大きいですか？インデックスを 2 つ (ナチュラル キーとサロゲート) ではなく 1 つ (ナチュラル キー) にすることで、スペースを節約します。
  5. 複合自然キー (識別関係の子エンドポイントにある) は、菱形の依存関係を正しくモデル化するために必要になる場合があります。
  6. サロゲートは、ORM ツールに対してより親しみやすいかもしれません。

ユーザー名の場合...

  1. おそらく、更新を許可する必要があります。
  2. ユーザー名だけを検索する必要はほとんどありません。
  3. ユーザー名の範囲スキャンは意味がありません (等検索とは異なります)。
  4. 地球の全人口を保存しているわけではありませんよね?
  5. ここでは、識別関係の結果である自然キーではなく、「スタンドアロン」の自然キーについて話しています。
  6. わからない？

...したがって、この場合、代理キーはおそらく正当化されます。

于 2012-07-24T20:57:42.083 に答える
3

ユーザー名は一意である可能性がありますが、通常は変更できないわけではなく、HLGEMがHLGEM_1になりたかったため、数千または数百万のレコードを変更する必要がないため、ユーザーIDを作成します。整数のさらなる結合はより高速です。

于 2012-07-24T19:33:49.810 に答える
3

2つの考え方があります。データベースの純粋主義者は、可能な限り常に自然キーを使用する必要があると信じています (そしてそれは理にかなっています)。したがって、その考えに同意し、ユーザー名を変更できない場合は、キーをユーザー名にします。

データベースのプラグマティストは、代理キーの方が有用であり、要件の変化によりよく耐える傾向があると考えています。場合によっては、特に大きな文字列キーを使用すると、より高速になることもあります。自然キーを使用すると、代理キーからは入手できない情報が漏洩する可能性があるという点で、セキュリティ上の懸念もあります。

于 2012-07-24T19:40:29.387 に答える