들어가며

DB 설계를 하면서 PK 데이터 타입을 선정하는데 가지고 있는 기준이 딱히 없어서,
이번 기회를 통하여 나름의 기준을 정립해본다.

Auto Increment PK 컬럼을 SEQ, 그 외에 PK 컬럼을 ID로 분류하여 정리해보았다.

ID 선택 가능한 상황

SEQ가 아닌 ID를 사용해볼만한 상황을 정리해보자.

사용자가 직접 ID를 입력해야하는 경우
- 대표적으로 사용자 계정 정보
- 아래는 Category 테이블의 path정보를 PK로하는 경우이다.
```
Category (path: '/관할구역/서울', ...)
Category (path: '/관할구역/대구', ...)
Category (path: '/관할구역/대구/1', ...)
```
- 계정 데이터 아닌 ID 값을 사용자가 입력해야 하는 경우는 사용자에게 표시되는 정보로 활용 할 경우이다.
시스템 생성 데이터인 경우이면서 ID값을 조건문에 활용하는 경우 아래는 ROLE 테이블의 ID 값을 활용하는 프로그램 예시이다.
```
if (role.id == 'ADMIN') ...
else if (rol.id == 'OPERATOR') ...
```

PK 테이블과 FK 테이블의 데이터수가 많은 경우는 각 테이블의 인덱스 크기에 영향을 주기 떄문에

신중히 생각해야 함. 정리하자면 아래와 같은 경우 ID 대신 SEQ를 사용하는 것이 바람직하다

PK 컬럼은 FK 테이블에 전파가 되기 때문에 데이터 타입을 신중하게 골라야 했다.

이번 설계 때 대부분은 SEQ를 PK로 하였지만, 몇몇 테이블은 위에 근거대로 ID를 PK로 선정하였다.

이번 기회로 PK 선정 기준 뿐만 아니라, 테이블 및 인덱스 크기에 따른 메모리 캐싱과 DISK I/O 관계에 대해 생각해본 기회가 되었다.