기본키 설계 - 자연키 VS 인조키

기본 키를 가진다.

기본키는 레코드를 식별하고 테이블 관계를 설정하기 위해 필요하다.

이 작업에서는 다음과 같은 부분을 고민했다.

‘기본키를 자연키로 가져갈까 인조키로 가져갈까?’

사실 다른 테이블들은 기본키로 구성할만한 자연키가 마땅히 없어서 모두 id라는 인조 필드를 만들고 기본키로 설정했다. 하지만 회원 테이블에서는 로그인 아이디를 기본키로 가져가도 되지 않을까?라는 생각이 들어 각각의 장단점을 비교해보았다.

자연키 장점

MySQL의 InnoDB스토리지 엔진의 경우 기본키를 바탕으로 테이블 자체가 클러스터링 인덱스가 되기 때문에 자연키를 기본키로 한다면 이 자연키를 위해 따로 인덱스를 구성할 필요가 없다.

커버링 인덱스가 작용할 가능성이 높다.

자연키 단점

비즈니스 요구사항의 변화로 인해서 기본키로 사용하던 자연키를 변경해야 할 수 있다.
예를 들어 회원 테이블에 주민번호를 기본키로 사용했는데 주민번호를 저장하지 못하도록 법이 개정되면 문제가 생길 수 있다.

자연키 예시 (초대코드)

중복 코드 생성을 낮추기 위해 경우의 수를 염두해야 한다.

    @Id
    @Column(name = "invite_code_id", nullable = false, length = 10)
    private String id;


	// inviteCode 생성
    private String issueInviteCode() {
        Random random = new Random();

        StringBuffer stringBuffer;
        do {
            stringBuffer = new StringBuffer();
            for (int i = 0; i < 8; i++) {
				{inviteCode 생성}
            }
        } while (생략);

        return stringBuffer.toString();
    }

인조키 장점

비즈니스 요구사항 변화에 전혀 영향받지 않기 때문에 변경할 일이 없다.

인조키 단점

인덱스를 추가로 구성해주어야 할 수 있다.

인조키를 위한 필드가 추가되어 테이블이 커진다.

자연키의 장점은 '성능', 인조키의 장점은 '유연성'이라고 할 수 있다.

'유연성'이 '성능'보다 우선순위가 높기 때문에 유저 테이블 또한 인조키를 기본키로 하기로 결정했다.

인조키 예시

jpa에서 자동으로 생성해준다.

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;