PK ) Auto Increment 와 UUID 에 대한 고민

 

회사를 들어오기 전에 나는 그랬다.

각각 테이블의 PK 를 Auto Increment 하고 그걸 그저 user 테이블과 외래키 관계를 두며 관계 설정을 했었다.

그런데 실무에서는 유저 PK 를 만들어 그것을 유저 관련된 다른 테이블에서도 PK를 같은 값으로 두더라고?

PK 를 직접 부여하는 방식으로 말이다.

-> 이거 우리 회사만 그런 거더라고,,, 다시 바꾸었다. 피엠님을 설득해서 이제는 테이블 고유 식별자를 따로 사용한다아,..

 

나는 지금 DB 구조 설계를 맡았다.(두둥)

그래서 그렇게 중요한 PrimaryKey 를 Auto Increment 할 것인가, 아님 UUID 로 부여할 것인가에 대해서 고찰해보았다.

 

UUID 로 PK 를 부여하는 것에 대해서는 이러한 장점이 있다

• 데이터베이스가 여러 개라면, 하나의 ID 가 여러 DB 에서도 고유한 값이 된다.
• 데이터 정보를 노출하지 않아 보안에 좋다. (숫자로 해놓으면 노출될 경우 데이터가 유출될 가능성이 높겠지?)
• 함수를 사용하여 키를 생성할 수 있으니 insert 할 때 그 전 유니크 키를 알기 위해 굳이 select 쿼리를 DB 에 요청하지 않아도 된다.

 

 

내가 개발해야하는 건 내부에서 사용하는 애플리케이션이고 다음과 같은 생각을 했다.

• DB 를 단 한 개만 사용한다면 장점이 될 수 없음.
• PK 는 Auto Increment 로 두되, 외부에 공개하는 키 값은 UUID 로 한다면 보안에 유리하다.
• 게다가 기업 내부 프로그램에서는 상대적으로 사용자들에게 공개하는 애플리케이션보다는 보안이 그렇게 중요하진 않음.(외부에 노출될 가능성이 적음)
• Insert 보다 조회 쿼리가 훨씬 많을 텐데, uuid 로 하면 조회 성능이 훨씬 떨어짐. 메모리도 많이 잡아먹구.
• 정렬도 Auto Increment 가 훨씬 유리함.
• AWS 는 DB가 서버가 재시작되더라도 자동 백업을 보장한다고 한다.
  • 다만, AWS 종속적이기 때문에 DB 내부에 INDEX 를 저장하는 안전 시스템은 필요하다.

 

어쨌든 이런 생각으로 Auto Increment 를 쓰는 게 낫다고 판단했다.

이제 모두를 설득해서 PK를 UUID 가 아니라 Auto Increment 로 사용하고 싶다…(PM님은 이미 설득함)

 

 

 

스타트업의 장점 —> 처음부터 새롭게 만들어갈 수 있음

을 제대로 느끼는 중…

 

변수명도 짓구 구글시트에 정리도 했음~~~~~~꺄옹^_^

 

아마 나중에 가서 이 방법이 비효율적이라는 걸 깨닫더라도 배우는 게 있고 보완할 점도 찾아가겠지? ㅎㅎ

이곳에서 스스로 생각하고 찾아보는 경험이 나를 더 성장시켰으면 좋겠다.

 

 

+)

결국 Auto Increment 를 사용하고 uuid 컬럼은 따로 두기로 ㅎ_ㅎ/) 뿌듯뿌듯!