03-05 06:46
Notice
Recent Posts
Recent Comments
Link
«   2025/03   »
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
Archives
관리 메뉴

기록을 합시다.

Email은 Primary Key가 될 수 있을까?(feat. 스택오버플로우) 본문

공부/DB

Email은 Primary Key가 될 수 있을까?(feat. 스택오버플로우)

울집고양이세마리 2023. 4. 13. 00:18

RDBMS 테이블을 작성하다가, 늘 INT auto_increment로 user_id를 생성해서 primary key로 사용하면 갑자기 의문이 들었다. 왜 email은 primary key로 안 쓰는 거지? 

 

모든 것에는 다 이유가 있는 법.. 검색을 해보니 이런 글이 떴다. (무려 12년전 글..)

https://stackoverflow.com/questions/3804108/use-email-address-as-primary-key

 

Use email address as primary key?

Is email address a bad candidate for primary when compared to auto incrementing numbers? Our web application needs the email address to be unique in the system. So, I thought of using email addre...

stackoverflow.com

위의 글과 댓글들을 대략적으로 정리해보자면 아래와 같다. 

 

  1. 문자열 비교(인덱스 검색)는 정수형 비교보다 느리다. email을 이용하는 단순한 쿼리를 이용하는 것이라면 상관 없다. 하지만 email을 primary key로 이용하게 된다면, 여러 테이블에서 foreign key로 설정하게 된다. 이 경우 복잡한 조인을 사용하게 된다면 쿼리 속도가 매우 느릴 것이다. 
  2. PK는 일정하고 고유해야 하기 때문에 변경될 수 있는 email을 PK로 지정하는 것은 옳지 않다. 
  3. 여러 테이블에서 email을 foreign key로 설정하게 된다면(컬럼) 문자열 크기 때문에 데이터베이스가 무거워진다. 

 

결론은 Email은 PK로 사용하기 적합하지 않다는 것이다. 

 

애초에 변경될 수 있다는 점에서 PK는 탈락이고, 문자형이라는 점에서 탈락인 것 같다. 

내가 왜 Email을 PK로 안 쓰냐는 의문점이 든 이유는 단순히 Email을 사람들(유저들)이 ID처럼 사용했기 때문이다. 

그런데 잘 생각해보니, 서비스 하는 애플리케이션에서도 ID로 쓰는 Email 정도는 바꾸게 해준다.

 

모든 것에는 이유가 있는 법..

Comments