mysql - Mysql - ID 列を使用する必要がありますか?

Question

ベスト プラクティスとデータベース エンジンの仕組みについて疑問があります。

次の列を持つ Employee というテーブルを作成するとします。

• SS ID (主キー)
• 名前
• セックス
• 年

問題は..すべてのテーブルにある多くのデータベースと、連続番号であるIDと呼ばれる追加の列が表示されます。ここでテーブルに ID フィールドを配置する必要がありますか? つまり、インデックスを作成する主キーが既にあります。シーケンシャル ID フィールドを使用すると、データベースはより高速に動作しますか? それを使用してテーブルをリンクしたり調査したりしないと、それがどのように役立つかわかりません。

それは役に立ちますか？もしそうなら、なぜ、データベースで何が起こるのですか?

ありがとう！

編集 ----- これはばかげた例です。SS_ID のことは忘れてください。主キーを選択するためのより良い方法があることはわかっています。主なトピックは、SQL クエリに使用しないことを知っていても、ID という名前の列を追加するように頼む人がいるからです。特に、Microsoft Access などの一部のデータベース ツールでは、この新しい列を追加するかどうかを常に尋ねられるため、データベースのパフォーマンスが何らかの形で役立つと考えているだけです。

これは間違っていますよね？

Answer 1

SS が「社会保障」を意味する場合、それを PK として使用しないことを強くお勧めします。自動インクリメント ID が最適です。

ビジネスロジックが組み込まれたキーを使用することはお勧めできません。多くの人は、SS 情報を提供することに神経質になっています。SS を主キーとして使用している場合、アプリはオーディエンスの一部を排除している可能性があります。HIPPA などの法律により、使用できなくなる可能性があります。

Answer 2

シーケンシャルを持つことによる実際のパフォーマンスの向上idは、テーブルの使用方法に大きく依存します。

• ORM フレームワークを使用している場合、これらは通常、整数型 [1] のシーケンシャル ID を持つ方がうまく機能します。これは通常、シーケンシャル id 列で実現されます。
• ORM フレームワークを使用しない場合、決して使用しないキーと、事実上常に使用するid代理キーを持つことはほとんど意味がありません。ss_id
• 他のデータベース テーブル (外部キー) から参照している場合、その整数を格納すると子テーブルに消費されるスペースが少なくなるため、employeesおそらく列を持つ方が効率的です(私が想定しているのはaまたは) どこでも。idss_idCHARVARCHAR

ではss_id、それが社会保障番号であると仮定すると（そうなるように見えます）、注意が必要な法的およびプライバシーの問題が付随する可能性があります-私の答えは、データベースに社会保障番号を含める正当な理由があることを前提としています.法的に使用および保管が許可されること。

[1] これは通常、ORM フレームワークが、典型的な ORM の使用に合わせて調整された、高度に特殊化されたキャッシュメカニズムを持つことに依存しているという事実によって説明されます。これは通常、連続したid主キーを持ち、アプリケーションが実際のビジネス ID を処理できるようにすることを意味します。これは実際、「外部キー」の考慮事項と非常によく似た考慮事項に関連しています。

Answer 3

米国の社会保障番号は十分に識別できません。そして、銀行は確かにそれらをそのように使用しません. 誰もが持っているわけではありません。エラーにより、重複が発生します。外国人は持っていません。データベース PK として使用するには脆弱すぎます。

最も重要なのは、死亡後に再利用されることです。

いくつかの調査を行います:主キーとしての SSN

Answer 4

(明らかに) もっと重要なことは、主キーに使用するデータが一意に識別可能である限り、主キーを持っていることです。あなたの例では、SSNは一意に識別できるため、銀行はそれらを使用して機能します。この例の問題点は、従業員 ID が他のテーブルで外部キーとして使用される可能性が高いことです。これは、(法的に保護されている) 個人情報を取得し、データ モデル全体に​​適用していることを意味します。この場合、Auto Incremented フィールドを使用したほうがよいかもしれません。