sql - ID列と主キー

Question

ID 列と主キーのどちらを使用するかをどのように決定できますか?

Answer 1

2つの概念は相互に排他的ではありません。すべての組み合わせが可能です：

• 主キーでもあるID列、
• 主キーではないID列、
• IDではない主キー列、
• 主キーでもIDでもない列

ID列は、一意であることが保証されているため、主キーとして使用されることが多く、通常は必須のスキーマフィールドに追加されるため、スキーマが変更されても変更されないことに注意してください。

Answer 2

自動インクリメントが必要な場合は、Identity 列を使用します。限目！そのような単純な。通常、ID 列は主キーの候補として適しています。

主キーは単なる概念です。主キーの背後にある重要なことは、列に CLUSTERED INDEX を作成することです。そのため、理論的には、一意のクラスター化インデックスを持つテーブルがある場合、「主キー」は必要ありません。

Google で検索して、理解することが非常に重要なこれら 2 つの概念について読むことをお勧めします。

Answer 3

理論ではなく経験から、ユーザーによって共有されていないキーを「ユーザーデータ」として使用することが重要であることを発見しました。つまり、ユーザー データとキーは異なるフィールドである必要があります。

プロジェクト コードを使用するデータベースがありました。プロジェクト コードは一意であり、空になることはなく、一度割り当てられると決して変更されないというビジネス ルールがありました。それが候補キーになります。

ただし、ユーザーがプロジェクト コードを表示したり、プロジェクト コードごとにファイルを検索したりする場合、それはユーザーのデータであり、プロジェクト コードに関するビジネス ルールを変更する必要があります。

私たちのプロジェクト コードは、顧客 ID の後にダッシュと一意にするためのシーケンス番号が続きます。ある顧客 ID に対して提案されたプロジェクトが別の顧客 ID の契約で終わった場合、ユーザーはプロジェクト コードを変更したいと考えました。ユーザーが間違った顧客 ID を入力した場合、プロジェクト コードを変更する必要がありました。主キーの変更と、それを参照するすべての外部キーには問題があります。

それは質問に答えていないようです（どうすればID列または主キーを使用するかを決定できますか？ ）

ただし、主キーに顧客データを使用しない場合 (そうすべきではないと主張したように)、ユーザーが入力することを期待できないため、主キーを自動生成する必要があります。

Answer 4

データベースをスケーラブルにするために、常に主キーを使用する必要があります。GUIDまたはUUIDまたはその他の一意のものを使用します。