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