실무에서의 대리키 사용

order_items 식별 방식

실무에서는 PK만 단일 id로 분리하고, 원래 식별 규칙은 UNIQUE(order_id, item_seq)로 남깁니다.

개념적으로 자연스러운 구조

복합키가 행의 정체성을 직접 표현

약한 개체는 보통 소유자 키와 부분 키를 합쳐 한 행을 구분합니다.

order_items ( order_id NUMBER, item_seq NUMBER, ... PRIMARY KEY (order_id, item_seq) )

실무에서 더 흔한 구조

업무상 유일성은 유지하되, 기본키와 참조 구조를 단순하게 가져갑니다.

order_items ( id NUMBER PRIMARY KEY, order_id NUMBER NOT NULL REFERENCES orders(id), item_seq NUMBER, ... UNIQUE (order_id, item_seq) )

핵심 보존점

대리키를 써도 한 주문 안에서 item_seq는 하나만 가능하다는 규칙은 그대로 유지됩니다. 달라지는 것은 PK의 모양이지, 데이터의 의미가 아닙니다.

실무에서 선호되는 이유

ORM 매핑

JPA, TypeORM 같은 ORM은 단일 PK를 다룰 때 엔티티 매핑과 식별자 취급이 더 단순합니다.

FK / JOIN

다른 테이블이 이 행을 참조할 때 컬럼 1개만 보면 되므로 조인 조건과 FK 관리가 가벼워집니다.

변경 영향

업무 키가 조정되더라도 PK 자체를 바꾸는 연쇄 영향이 줄어 운영 변경에 더 유연합니다.

이론적으로는 약한 개체의 의미를 가장 직접 드러내는 쪽이 복합키입니다. 그래서 실무의 대리키는 “정체성을 버린 선택”이 아니라 “PK 역할을 따로 뽑아낸 운영상의 선택”으로 이해하면 됩니다.