JPA로 엔티티를 설계하던 중 의문이 들었다. 보통 PK는 @GeneratedValue 어노테이션으로 artificial key를 사용한다.
계정 정보를 나타내는 엔티티는 로그인 아이디를 컬럼으로 가지고 있고, 그 컬럼은 Updatable = false, unique = true, nullable = false를 제약조건을 가지고 있다.
그렇다면 변경이 불가능하고, 유일하고, 값이 있어야 하는 로그인 아이디는 PK와 비슷해보인다. 그렇다면 로그인 아이디를 PK로 사용하면 되지 않을까?
인프런에서 JPA 수업을 들었던 김영한 팀장님께 물어봤다. 언제나 친절하게 답변해주신다.
대부분의 사이트들이 고객 id를 PK로 잡지않는다고 한다. 로그인 아이디는 비지니스 로직과는 무관해보이지만 그렇지 않다.
login id의 제약조건 그 자체가 비지니스 로직이기 때문이다. 예를들어 로그인 아이디의 최소, 최대 길이가 변할 수도 있다.
예전 모 사이트에서는 주민등록번호를 pk로 사용했었다는데 개인정보보호법이 강화되어 주민등록번호 사용이 불가능해지자 많은 코드를 수정했어야 했던 적도 있다고 한다.
Tracable한 엔티티를 만들기 위해 id는 artificial key를 사용하자. 쿼리에 자주 사용되는 로그인 아이디는 인덱싱을 해야겠다.
'데이터베이스' 카테고리의 다른 글
Shared Lock 과 Exclusive Lock (0) | 2021.12.05 |
---|---|
Join 쿼리를 어떻게 최적화할까 (0) | 2021.03.10 |
Narrative to ERD - Individual Assignment #3 (0) | 2020.12.23 |
Nested Query - Individual Assignment #2 (0) | 2020.12.23 |
Usage of Join - Individual Assignment #1 (0) | 2020.12.23 |