1:N 관계에서는 보통 외래 키(FK)를 **"N 쪽"**에 둔다. 하지만 1:1 관계에서는 양쪽 모두 최대 1개이기 때문에, 다음처럼 선택지가 생긴다.

1. A 테이블에 B의 PK를 가리키는 FK를 둔다.
2. B 테이블에 A의 PK를 가리키는 FK를 둔다.
3. A, B가 같은 PK를 공유하고, 한쪽이 동시에 PK이자 FK가 된다.

이때 설계에서 가장 중요한 질문은 다음과 같다.

"두 테이블 중에서 어느 쪽이 주(主) 테이블이고, 어느 쪽이 부가(상세) 테이블인가?"

실무에서는 보통:

• 주 테이블: 존재 자체가 먼저 결정되는 엔티티 (예: member)
• 상세 테이블: 주 테이블이 있을 때만 의미가 있는 엔티티 (예: member_profile, member_sensitive)

로 보고, 상세 테이블이 주 테이블을 FK로 참조하는 방식을 사용한다.

CREATE TABLE member (
  member_id BIGINT PRIMARY KEY,
  name      VARCHAR(50) NOT NULL
);

CREATE TABLE member_profile (
  member_id BIGINT PRIMARY KEY, -- PK 이자 FK
  intro     TEXT,
  CONSTRAINT fk_member_profile_member
    FOREIGN KEY (member_id) REFERENCES member(member_id)
);

이 설계에서는 다음이 보장된다.

• member_profile.member_id는 항상 이미 존재하는 회원만 가리킨다.
• 회원이 삭제되면(ON DELETE 정책에 따라) 프로필도 같이 삭제하거나, FK 제약으로 삭제를 막을 수 있다.
• 프로필이 없는 회원은 단순히 member_profile에 행이 없으면 된다.

반대로, 주 테이블에 FK를 두면 여러 문제가 생긴다.

CREATE TABLE member (
  member_id       BIGINT PRIMARY KEY,
  name            VARCHAR(50) NOT NULL,
  profile_id      BIGINT,           -- 프로필 테이블 FK
  CONSTRAINT fk_member_profile
    FOREIGN KEY (profile_id) REFERENCES member_profile(id)
);

이 구조는 다음과 같은 단점이 있다.

• 프로필이 없어도 profile_id 컬럼이 항상 따라다닌다.
• 나중에 프로필 테이블을 여러 개로 쪼개고 싶을 때(예: 일반 프로필, 프리미엄 프로필 등) 확장성이 떨어진다.