7-1. 연결 테이블에 속성이 생기는 순간

연결 테이블이 단순히 두 FK만 가지지 않고, 자체 속성이 늘어나기 시작하면 이야기가 달라진다.

예: 회원–쿠폰 관계에 다음 정보를 추가한다고 가정한다.

• used_yn : 사용 여부
• used_at : 사용 일시
• expired_at : 만료 일시

이때 member_coupon은 더 이상 단순한 관계가 아니라, 고유한 의미와 상태를 가지는 독립 엔티티에 가까워진다. 이런 경우에는 다음처럼 설계하는 편이 더 현대적인 방식이다.

CREATE TABLE member_coupon_new (
  member_coupon_id BIGINT NOT NULL AUTO_INCREMENT,  -- 대리 키 PK
  member_id        BIGINT NOT NULL,                 -- FK
  coupon_id        BIGINT NOT NULL,                 -- FK
  issued_at        DATETIME NOT NULL,
  used_yn          CHAR(1)     NOT NULL DEFAULT 'N',
  used_at          DATETIME,
  expired_at       DATETIME,
  PRIMARY KEY (member_coupon_id),
  UNIQUE (member_id, coupon_id),                    -- 중복 발급 방지
  CONSTRAINT fk_mc_member
    FOREIGN KEY (member_id) REFERENCES member (member_id),
  CONSTRAINT fk_mc_coupon
    FOREIGN KEY (coupon_id) REFERENCES coupon (coupon_id)
);

• PK는 member_coupon_id라는 대리 키로 바꾸고,
• (member_id, coupon_id)에는 UNIQUE 제약으로 비즈니스 규칙을 표현한다.
• 부모와의 관계는 비식별 관계로 유지한다.

이렇게 하면 연결 테이블이 점점 커지더라도 구조가 복잡해지지 않는다.

7-2. 실무적인 가이드

• 단순히 두 PK만 이어주는 순수 관계 테이블이라면, (parent1_id, parent2_id) 복합 PK 사용도 가능하다.
• 하지만 연결 테이블에 속성이 붙기 시작하면, 대리 키 + 비식별 관계로 전환하는 것이 좋다.
• 특히 ORM, 마이그레이션, 추후 기능 확장을 고려하면 대리 키 구조가 더 유연하다.