본질식별자 vs 인조식별자 정의

 

1) 본질식별자 vs 인조식별자 한 줄 정의

• 본질식별자(자연키): 업무에서 원래 존재하는 “의미 있는” 고유값
  예) 학번, 사번, 사업자등록번호(업무 식별용), 과목코드
• 인조식별자(대리키): 시스템이 새로 만들어 붙이는 “의미 없는” 번호
  예) 회원ID(자동증가), 주문행ID(SEQ), 등록ID

---

2) 예시로 바로 이해(학생)

본질식별자 예

• 학생 엔티티에서 학번은 입학 시 부여되는 고유값
  → 학번만으로 학생 1명을 구분 가능
  그래서 학번은 본질식별자(PK로 쓰기 좋음)

인조식별자 예

• “학기별 성적/수강내역” 같은 테이블은 학번만으로는 행이 유일하지 않음
  • 같은 학생이 여러 학기, 여러 과목을 가지니까요.
• 이럴 때 등록ID 같은 인조식별자를 PK로 만들 수 있습니다.

---

3) 인조식별자가 필요한 대표 상황(이미지 핵심: 주문상세)

문제 상황(복합키/순번 관리가 번거로움)

주문상세가 이렇게 생겼다고 해봅시다.

• 주문번호만으로는 행이 구분되지 않아서 주문순번을 관리해야 함
• “순번”은 사람이 계산/관리해야 해서 실수 가능성이 큼

해결(인조식별자 도입)

• DB가 주문행ID를 자동 생성(SEQ 등)
  행을 구분하기 훨씬 쉬워지고, 순번 관리도 필요 없어짐

---

4) 인조식별자의 장점(이미지 요약)

1. 고유성 보장 쉬움
   • 시스템이 자동으로 유일값을 만들어 줌
2. 조회/수정/삭제가 단순해짐
   • PK가 하나의 컬럼이라 SQL 조건이 깔끔
3. 성능/인덱싱에 유리한 경우가 많음
   • 짧고 단순한 키는 인덱스/조인에서 유리
4. 관계(조인) 설정이 쉬워짐
   • 여러 테이블에서 복합키를 끌고 다닐 필요가 줄어듦

---

5) 인조식별자 사용 시 주의점/단점(이미지 핵심)

① “중복 데이터”를 막아주진 않는다

인조식별자는 행을 구분하는 번호일 뿐,
“같은 사람이 중복 등록되는 문제”를 자동으로 막지 못합니다.

예) 고객 테이블에서

• 서로 다른 고객ID가 붙었지만 실제로는 같은 사람일 수 있음
  그래서 업무적으로 유일해야 하는 값(예: 이메일, 주민번호 대체값 등)은
  별도로 UNIQUE 제약 등을 걸어 중복을 막아야 합니다.

② 불필요한 인덱스가 늘어날 수 있음

• 인조식별자를 PK로 쓰면 자동으로 인덱스가 생기는 경우가 많고,
• 테이블이 많아질수록 인덱스 관리 비용이 커질 수 있음
  → “무조건 인조식별자”가 아니라 필요한 곳에만 쓰는 게 중요

---

초간단 결론

• 본질식별자: 업무에 원래 있는 고유값(의미 있음) → 가능하면 활용
• 인조식별자: 시스템이 만든 번호(의미 없음) → 복합키가 복잡하거나 관리가 어려울 때 유용
• 인조식별자를 써도 중복 데이터 방지 규칙(UNIQUE 등)은 따로 설계해야 함