앞에서 본 것처럼 1:1 관계에서 FK를 상세 테이블에 두는 것이 일반적인 패턴이다. 하지만 반대로 주 테이블에 FK를 두는 설계도 가능하다.

4-1. 주 테이블에 FK를 둔 설계 예시

CREATE TABLE profile (
  profile_id BIGINT PRIMARY KEY,
  intro      TEXT
);

CREATE TABLE member (
  member_id   BIGINT PRIMARY KEY,
  name        VARCHAR(50) NOT NULL,
  profile_id  BIGINT UNIQUE,
  CONSTRAINT fk_member_profile
    FOREIGN KEY (profile_id) REFERENCES profile(profile_id)
);

이 설계에서 1:1 관계를 보장하는 요소는 다음 두 가지다.

1. member.profile_id가 프로필 PK를 FK로 참조한다.
2. member.profile_id에 UNIQUE 제약을 걸어서, 하나의 프로필이 여러 회원에게 연결되지 못하도록 한다.

즉, 한 프로필은 최대 한 명의 회원과만 연결된다.

4-2. 주 테이블에 FK를 둘 때의 단점

그러나 이런 구조에는 다음과 같은 단점이 있다.

• 프로필이 선택적일 경우 profile_id는 NULL 허용 컬럼이 되어야 한다.
• 회원과 연관된 1:1 확장 정보가 늘어날수록, 주 테이블의 컬럼이 계속 추가된다.
  • profile_id, premium_profile_id, security_profile_id …
• 주 테이블 한 행만 보고는 현재 어떤 확장 정보가 실제로 존재하는지 헷갈리기 쉽다.

반대로 상세 테이블이 FK를 갖는 설계에서는:

• 주 테이블은 항상 핵심 정보만 유지하고,
• 확장 테이블은 필요할 때만 행이 생기므로,
• 테이블 간 관계를 시각적으로 파악하기가 더 쉽다.

그래서 1:1 관계에서는 특별한 이유가 없다면 주 테이블 → 상세 테이블이 아니라, 상세 테이블 → 주 테이블방향으로 FK를 두는 설계를 기본값으로 가져가는 편이 좋다.