본질식별자와 인조식별자

본질 식별자 vs 인조 식별자 비교

본질 식별자

업무에 의해 만들어진 식별자
장점
- PK 인덱스 활용 가능

인조 식별자

업무적으로 만들어지지는 않지만 본질 식별자가 복잡한 구성을 갖고 있어 인위적으로 만든 식별자
후보 식별자 중 PK로 선정할만 한 것이 없을 때 사용
장점
- 모델이나 SQL이 간단해짐
단점
- 인스턴스 생성 기준을 인조 식별자만으로 판단하기 어려움
- 모델만 보고 업무를 이해하기 어려움, 특히 행위 엔터티에서 가독성이 저하됨
- 유니크 인덱스를 추가로 사용하여 추가적으로 키를 관리해야 함
- 중복 데이터로 인한 품질 문제
  PK를 인조 식별자로 구성한 경우, PK 제약은 인조식별ID에 대해 적용되어 있기 때문에 중복 데이터가 발생하더라도 DBMS에서는 막을 수 없기 때문에 애플리케이션 단에서 처리해야 하는 문제 발생
아래와 같은 경우, 인조 식별자를 사용하는 것이 나을 수 있음
- 복합키의 변경이 빈번할 경우
- 복합키가 4개 이상일 경우
AUTO-INCREMENT 컬럼을 인조 식별자로 사용할 경우
- 보조 인덱스도 필요하고, PK의 크기도 같을 때

결론

PK는 가능하다면 AUTO-INCREMENT 컬럼(인조 식별자)보다는 업무적인 컬럼(본질 식별자)으로 생성할 것
- InnoDB의 PK는 클러스터 키로 사용되며, 이 값에 의해 레코드의 위치가 결정됨
- 즉, PK로 검색하는 경우 논클러스터 테이블에 비해 매우 빠른 처리가 가능하여 InnoDB에서는 성능에 큰 차이가 발생함
- 그러므로 컬럼의 크기가 크더라도 업무적으로 해당 레코드를 대표할 수 있다면 그 컬럼을 PK로 설정하는 것이 좋음
인조 식별자의 남용을 피하고 꼭 필요한 경우에만 사용하는 것을 권장함
- 인조 식별자는 불필요한 인덱스를 추가 생성해야 하고, 추가로 생성한 인덱스는 용량과 DML 성능에 영향을 줄 수 있음

참고링크

티스토리툴바