[Database Mysql] 기본키 (Primary key ) 타입 - Auto Increment? INT? VARCHAR?

기본키 (Primary key ) 타입 - INT? VARCHAR?

 

기본키 (Primary key )

---

데이터베이스를 연결하기 위해 사용된 고유한 식별자로서,

속성 혹은 열의 값이 지형지물군 내의 각 개체를 고유하게 식별하는 속성 혹은 열을 말한다.

 

참조 : https://terms.naver.com/entry.naver?docId=3481167&cid=58439&categoryId=58439

 

기본키 (Primary key ) 조건

---

1. 널 값을 가질 수 있는 속성이 포함된 후보키는 기본키로 부적합하다.
2. 값이 자주 변경될 수 있는 속성이 포함된 후보키는 기본키로 부적합하다.
3. 단순한 후보키를 기본키로 선택한다

참조 : https://terms.naver.com/entry.naver?docId=3431150&cid=58430&categoryId=58430

 

 

Auto Increment(인조키)

---

1. 데이터 계수기가 메모리 참조 명령의 끝에서 1만큼씩 증가되는 것. 1바이트의 명령으로 메모리 참조와 데이터 계수기의 증가를 동시에 행한다.
2. 로그성이나 게시판성 테이블에서 적합하다.

 

VARCHAR

---

자연어 : 자료의 실제 테이터에서 나온 key
비지니스 요구사항 측면에서 실제 테이터를 key로 사용하는것이 적합하지만, WHITE SPACE(공백) 발생 가능성이 있다.

UUID : 범용 고유 식별자

 

- UUID 버전 1: 네트워크 카드의 MAC주소(48비트)와 현재 시각(60비트)을 기반으로 uuid를 생성한다. 여기서 말하는 현재 시각은 1582년 10월 15일과 현재 시각의 nanosecond의 차이를 말한다. 3603년도까지 가능하다고 한다.

Mysql 에서는 UUID 버전 1 (MAC 주소) 를 지원한다.

단점
- MAC 주소를 포함하여 보안에 취약하다.

- Replication(복제) 환경에서 서버가 동일 할 경우 uuid가 동일하게 설정되므로, 마스터서버(읽기전용)서버에서 Slave(쓰기)서버로 replication 을 시작하면 UUID 중복 에러가 발생한다.

참고 :  https://ko.wikipedia.org/wiki/%EB%B2%94%EC%9A%A9_%EA%B3%A0%EC%9C%A0_%EC%8B%9D%EB%B3%84%EC%9E%90
참고: https://cleanupthedesk.tistory.com/15

범용 고유 식별자 - 위키백과, 우리 모두의 백과사전

MySQL DB replication 구성하기

 

- UUID 버전 4 : Java 에서는 UUID 버전 4(랜덤)를 지원한다.

매 초 10억개의 uuid를 100년에 걸쳐서 생성할 때 단 하나의 uuid가 중복될 확률은 50% 이다.

참고 : https://velog.io/@koreanhole/UUID%EA%B0%80-%EA%B2%B9%EC%B9%98%EB%A9%B4-%EC%96%B4%EC%A9%8C%EC%A7%80

UUID.randomUUID().toString().replace("-", "")

UUID의 '-'를 제거하여 sql 에서 UNHEX로 변환하여 insert 시 BINARY 16 으로 자료 크기를 줄일 수 있다.

참고 : http://daplus.net/java-java%EC%97%90%EC%84%9C-uuid-%EB%AC%B8%EC%9E%90%EC%97%B4%EC%9D%84-%EC%83%9D%EC%84%B1%ED%95%98%EB%8A%94-%ED%9A%A8%EC%9C%A8%EC%A0%81%EC%9D%B8-%EB%B0%A9%EB%B2%95-%EB%8C%80%EC%8B%9C%EC%97%86/

[java] JAVA에서 UUID 문자열을 생성하는 효율적인 방법 (대시없이 UUID.randomUUID (). toString ()) - 리뷰나

 

UUID 4로 PK를 생성할 경우,

PK로 어떤 정보를 내포하고 있는지 알 수 없기 때문에 다음 PK도 예측할 수 없다.

 

 

그래도 혹시 INSERT 시에 중복(Duplicate) 키 에러가 발생 할 수 있다는 가정으로 대처방법을 찾아봤고
아래 링크의 방법을 참고 했다.

https://umanking.github.io/2021/07/05/mysql-duplicate-record/

[java] JAVA에서 UUID 문자열을 생성하는 효율적인 방법 (대시없이 UUID.randomUUID (). toString ()) - 리뷰나

 

하지만 INT 대비 동적 쿼리의 속도가 느리다.

 

참고: https://velog.io/@devkingsejong/RDB%EC%97%90%EC%84%9C-UUID%EB%A5%BC-%EB%AC%B4%EC%9E%91%EC%A0%95-%EC%82%AC%EC%9A%A9%ED%95%98%EC%A7%80-%EB%A7%90%EC%95%84%EC%95%BC-%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0

RDB에서 UUID를 사용할 때 고민해볼점

참고 : https://stackoverflow.com/questions/2103322/varchar-as-foreign-key-primary-key-in-database-good-or-bad

VARCHAR as foreign key/primary key in database good or bad?

 

INT

---

1. 주문번호등 숫자의 의미가 부여 될때 사용된다.
2. 경우에 따라서 동적 쿼리 시 VARCHAR보다 실행 속도가 빠를 수 있다.

 

결론

---

정해진건 없으며, 업무적인 측면에서 PK에 정보를 내포해야하는지 여부와 자료 타입을 정해야 한다.