지금까지 내용을 토대로, 현대적인 RDB 설계에서 많이 사용하는 원칙을 요약하면 다음과 같다.

8-1. 대리 키 + 비식별 관계가 기본값

• PK는 비즈니스와 무관한 대리 키(id) 로 둔다.
  • 예: member_id, order_id, product_id 등 AUTO_INCREMENT 또는 UUID
• 자연 키(주민등록번호, 이메일, 주문 번호 등)는 UNIQUE 제약을 가진 일반 컬럼으로 둔다.
• 테이블 간 관계는 기본적으로 **비식별 관계(FK는 일반 컬럼)**로 설계한다.

즉, 한 문장으로 정리하면 다음과 같다.

대리 키 = PK, 자연 키 = UNIQUE, 관계 = 비식별

이 조합이 변경에 가장 강하고, 유지보수 부담이 적다.

8-2. 책임 분리

• 신원(Identity)
  • 변하지 않는 PK 대리 키가 담당한다.
• 관계(Relationship)
  • FK가 담당한다. 관계가 바뀌면 FK만 수정하면 된다.
• 비즈니스 데이터
  • 일반 컬럼이 담당한다. 규칙이 바뀌면 해당 컬럼만 수정·삭제하면 된다.

이렇게 역할을 분리하면, 비즈니스 규칙이나 관계 구조가 바뀌어도 PK를 건드리지 않고 대응할 수 있다.

8-3. 언제 식별 관계를 고려할 수 있는가

• 데이터가 매우 작고, 모델 구조가 오랫동안 바뀌지 않을 것이 거의 확실한 경우
• 순수한 관계 테이블(예: (parent_id, child_id)만 있는 조인 테이블)에서 복합 PK로 단순하게 끝내고 싶은 경우
• 일부 OLAP/데이터 웨어하우스에서 읽기 최적화만 극단적으로 추구할 때

하지만 일반적인 웹 서비스, 백엔드 시스템, 비즈니스 애플리케이션에서는 비식별 관계가 사실상 표준이라고 봐도 된다.