기획 내용
기획 회의에서 회원이 탈퇴할 경우 에브리타임 어플처럼 유저 정보가 탈퇴회원 기본 정보로(ex: 닉네임 - "알 수 없음") 변경되고 게시물 및 댓글 데이터는 그대로 유지되어 어플 내에도 그대로 보여지도록 정의했다.
탈퇴 요청 시 DB User 테이블 정보만 일괄적으로 동일하게 수정되도록 로직을 구현하고 개발완료했는데 클라이언트분에게 동일한 유저가 가입-탈퇴-재가입-탈퇴를 할 때 탈퇴 처리에서 에러가 난다는 카톡을 받았다.
에러 파악
서버에서 확인해보니까 처음 탈퇴할 때는 정상적으로 처리가 되는데 재가입 후 한번더 탈퇴를 요청하면 정말 오류가 났다. 정확한 단어까지는 기억이 안 나는데 이런식으로 오류가 떠있었다. SQL 오류라고 되어있는 것 같아서 DB쪽을 확인해봐야겠다고 생각했다.
Duplicate entry '2918' for key 'UQ_User_1'원인
User 테이블에 DDL을 확인해보니까 UNIQUE Constraint(email)이 보였다. email을 유니크한 컬럼으로 잡아놔서 탈퇴 회원이 1명이라도 존재하는 경우 탈퇴처리가 불가능해지는 것이었다!
예전에 처음 프로젝트 세팅할 때 다른 팀원분이 email 컬럼에 @Column(unique = true)을 설정해놔서 DB 설정값이 자동으로 세팅된 상황이었다.
맨 처음 커밋내역에 포함되어 있는 것을 보니 팀원분이 인덱스 관련해서 추가해놓은 것은 아닌 것 같고 단순하게 email은 중복이 안되니까~ 의 의미로 추가해놓은 것 같다. 오늘 회의에서 물어봐야딩 ~
해결 방법
-
탈퇴 회원은 User 테이블에서 아예 삭제시킨다.
→ 발생할 수 있는 문제점 : 글, 댓글 관련 조회 API에서 유저 정보가 null 값으로 리턴됨. userId 기준으로 조인해서 뽑는 형태라서 이렇게 처리한다면 다른 팀원들이 수정해야할 코드가 많아짐. 일괄적으로 탈퇴 회원 정보를 리턴해주기가 어렵다. -
DB에는 지금처럼 알수없음 회원으로 남겨두고 Unique 제약조건을 삭제한다.
→ 발생할 수 있는 문제점
-
중복 이메일이 생길 가능성이 존재한다
→ 해당 문제점은 코드 상에서 커버 가능하다고 생각했다. validation 처리를 해주고 있음. 그리고 이메일 똑같은 사람이 있을까? 🤔 -
이메일 인덱스를 활용한 쿼리가 있다면 검색속도가 느려질 수도 있다
→ 대부분의 쿼리에서 조인시에 id를 사용하고 있기 때문에 검색 속도에 영향을 받을 만한 쿼리가 없다고 판단했다. 또한 회원 탈퇴 및 가입이 잦게 발생할 경우 인덱스 수정에 따른 오버헤드가 생길 수 있는 단점이 존재한다고 생각이 들었다.
@Column(unique = true)의 기능 사용에 대한 글
- 탈퇴된 회원의 email 컬럼은 null로 저장한다.
- unique key는 null값 가능하다
선택!
2번으로 처리했다.
이러나저러나 유니크 설정을 없애는게 맞다는 생각이 들었고 삭제했다!
팀원들에게 한번 물어봐야겠다
Unique Key, Unique Index
에러메시지 속의 key 'UQ_User_1'
Unique 제약조건도 key가 생성된다는 것을 알게되었다
얼마전에 책에서 인덱스 관련 글만 읽고 실제로는 처음 봤는데 신기했당
이참에 정리하면
PK 기본키
- 중복 불가능
- null 값 불가능
- 테이블당 1개만 가능 (복합키 가능)
UQ 유니크키
- 중복 불가능
- null 값 가능
- 여러개의 컬럼 생성 가능
→ 중복값을 허용하지 않고 인덱스를 설정하고 싶을 때 사용하면 좋다
