이메일 인증 테이블을 별도로 분리한 이유




이메일 인증을 위한 테이블을 별도로 분리하였다.

거두절미하고, 기존 테이블과 변경 된 테이블을 살펴보자

이메일인증변경전
우선 기존 테이블은, 회원가입시 유저의 이메일 인증을 위한 인증번호를 user 테이블에서 가지고 있었다.

그런데 예상하지 못한 상황이 생겼다.

로그인 하지 않은 상태에서, 비밀번호를 찾기 위해서도 이메일 인증을 받아야하는데 그 인증 번호는 어디에 저장하지?

해당 질문에 가능한 대답은 2가지가 있었다.

  1. 비밀번호 찾기를 한다는 것은, 어차피 이메일 인증을 우선적으로 마쳤다는 것이니, 비밀번호 찾기를 위한 번호로 user 테이블의 email_auth 를 변경한다.
  2. 이메일 인증 코드를 위한 테이블을 별도로 마련한다.


사실 테이블을 바꾼 지금 1번의 대답이 얼마나 멍청한 대답이었는지를 이제는 안다..ㅋㅋㅋㅋ

is_email_auth의 경우 회원의 이메일 인증 여부이니 user 테이블이 갖고 있는 것이 맞다.

하지만 한번 사용하면 더이상 필요없는 이메일 인증 번호가 user 테이블에 저장되어 있는 것이 맞는가?

아니라고 생각한다.

이걸 왜 설계때는 못알아챘을까 싶을 정도로 당연히 테이블을 분리해야하는 내용이었다. (이메일 인증 번호가 회원가입, 비밀번호 찾기 두가지가 아닌 회원가입 하나의 경우였더라도..!)

그래서 이것을 깨달은 지금, 테이블은 다음과 같이 변경되었다.

이메일인증_변경후

회원은 회원가입을 위한 이메일인 인증이 되었는가의 여부인 is_email_auth만 가지고 있고,

인증 번호, 인증 유형은 user_auth 테이블에 별도로 저장이 된다.

아주 깔끔한 방법이라고 생각이 든다…!

이걸 왜 못봤지…못본 내자신 반성하자!