外部キーを主キーとして使用しても大丈夫ですか？
2つのテーブルがあります。
- ユーザー（ユーザー名、パスワード）
- プロファイル（profileId、gender、dateofbirth、...）
現在、私はこのアプローチを使用しています。各プロファイルレコードには、「userId」という名前のフィールドがあります外部キー Userテーブルにリンクします。ユーザーが登録すると、プロファイルレコードが自動的に作成されます。
友達の提案と混同されています。「userId」フィールドをforeignおよびprimaryキーとして使用し、「profileId」フィールドを削除します。どのアプローチが良いですか？
外部キーは、ほとんどの場合「重複を許可する」ため、主キーとしては不適切です。
代わりに、テーブル内の各レコードを一意に識別するフィールドを見つけるか、主キーとして機能する新しいフィールド（自動インクリメント整数またはGUID）を追加します。
これの唯一の例外は、 one-to-one のテーブルです=関係。ここで、リンクされたテーブルのforeignキーとprimaryキーは同一です。
主キーは常に一意である必要があり、外部キーはテーブルが1対多の関係である場合、一意でない値を許可する必要があります。テーブルが1対多の関係ではなく、1対1の関係で接続されている場合、外部キーを主キーとして使用することはまったく問題ありません。同じユーザーレコードに複数の関連プロファイルレコードがある可能性がある場合は、別のプライマリキーを使用します。
一般に、1対1の関係を持つことは悪い習慣と考えられています。これは、1つのテーブルにデータを表示するだけで同じ結果が得られるためです。
ただし、参照しているテーブルにこれらの変更を加えることができない場合があります。この場合、外部キーを主キーとして使用しても問題はありません。自動インクリメントする一意のプライマリキーと外部キーで構成される複合キーを使用すると役立つ場合があります。
現在、ユーザーがログインしてアプリで使用する登録コードを生成できるシステムで作業しています。入らない理由のため、ユーザーテーブルに必要な列を単に追加することはできません。そのため、コードテーブルを使用して1対1のルートをたどっていきます。
はい、外部キーは、それらのテーブル間の1対1の関係の場合に主キーになることができます
はい、主キーを外部キーにすることは合法です。これはまれな構成ですが、以下に適用されます。
1：1の関係。 2つのテーブルを1つにマージすることはできません。異なるアクセス許可と特権がテーブルレベルでのみ適用されるためです（2017年現在、このようなデータベースは奇妙です）。
1：0..1の関係。ユーザーのタイプに応じて、プロファイルが存在する場合と存在しない場合があります。
パフォーマンスは問題であり、設計はパーティションとして機能します。プロファイルテーブルはほとんどアクセスされず、別のディスクでホストされるか、ユーザーテーブルとは異なるシャーディングポリシーを持ちます。下線のストレージが円柱状の場合は意味がありません。
私はそうしません。 profileIDをテーブルの主キーとして保持しますProfile
外部キーは、2つのテーブル間の単なる参照制約です
主キーは、他のテーブルからそれを参照する外部キーのターゲットとして必要であると主張することができます。外部キーは、いくつかのテーブルのプライマリキー列で見つかった値を保持できるテーブルの1つ以上の列のセットです（そのテーブルのプライマリキーはもちろん、候補キーである必要はありません）他のテーブル。したがって、外部キーと一致する主キーが必要です。それとも私たちは必要ですか主キー/外部キーのペアの主キーの唯一の目的は、明確な結合を提供することです-参照される主キーを保持する「外部」テーブルに関する参照整合性を維持するためです。これにより、外部キーが参照する値が常に有効（または許可されている場合はnull）になることが保証されます。
それはビジネスとシステムに依存します。
UserIdが一意であり、常に一意である場合、userIdを主キーとして使用できます。しかし、システムを拡張したい場合は、物事が難しくなります。テーブルプロファイルに外部キーを追加するのではなく、テーブルプロファイルに外部キーを追加して、テーブルプロファイルとの関係を作成することをお勧めします。
短い答え：DEPENDS ....この特定のケースでは、それは問題ないかもしれません。ただし、専門家はほぼ毎回それを推奨します。あなたのケースを含む。
どうして？
キーが問題のテーブルに対して外部にある（別のテーブルに由来する）場合、キーがテーブルで一意になることはほとんどありません。たとえば、アイテムIDは、同じタイプのアイテムが別の注文に存在する可能性が高いため、ITEMSテーブルでは一意ですが、ORDERSテーブルでは一意ではない場合があります。同様に、注文IDはORDERSテーブル内で一意（可能性あり）ですが、複数の品目の注文が存在する可能性があるORDER_DETAILSなどの他のテーブルではなく、特定の順序で特定のアイテムに対してクエリを実行するには、2つの連結が必要ですこのテーブルのPKとしてのFK（order_idおよびitem_id）。
私はDBの専門家ではありませんが、PKとして自動生成された値を持つことを論理的に正当化できる場合は、それを行います。これが実用的でない場合、2つ（またはそれ以上）のFKの連結がPKとして機能します。しかし、単一のFK値をPKとして正当化できるケースは考えられません。