기존에 포스팅했던 모델링을 이어나가고 있다. 포스팅은 뜸해도 수정은 계속 해왔다.
erdCloud의 다른 디비 설계를 참고하면서 책의 이론도 외우는 식으로 공부하고 있다.
오늘은 회원쪽 관련해서 수정이 있었다.
내가 던진 질문
1. 회원 테이블에서 로그인 방식과 가입 방식 모두 일반과 소셜로 나뉜다. 중복 아닌가? 더 나은 방법이 없나?
=> 만약 가입 방식을 별도의 테이블로 분리한다면 테이블명이나 컬럼명은 어떻게 하는 게 맞는지,
나는 결국 로그아웃할 때 로그인한 수단을 알아야 하는데 이걸 어떻게 얻을까에 대한 고민이었다.
하지만 로그인 방식과 가입 방식은 한 계정 내에서 동일하다. 그러니 둘 다 컬럼을 추가해서 관리하는 것이 아니라 가입 방식만 추가하고 로그인 방식 시 이 값을 꺼내오도록 한다. 로그인 방식은 결국 계산된 값이라는 것이 된다.
회원은 1개 이상의 계정을 가질 수 있다. 소셜 로그인 때문이다.
소셜 로그인 시 자동으로 회원가입이 되도록 기능을 짤 것이다.
소셜 로그인을 했던 계정(이메일)으로 일반 회원가입을 시도하면 "이미 가입된 계정입니다." 표시한다.
내가 일반 방식으로 A계정을 가지고 가입을 해도, B계정으로 소셜 로그인을 통한 가입을 할 수도 있다.
처음에는 그래서 "아, n개의 계정을 가질 수 있으니 가입정보를 별도 테이블로 빼야 하는 것 아닌가?"
하는 생각에 아래처럼 만들었다.
어 그런데 다시 생각해보니 회원아이디가(user_id) 다르기 때문에 가입수단과 그에 따른 상태코드가 여러 개여도 레코드 중복은 일어나지 않는다.
나는 지금까지 다중 값을 가지는 컬럼을 상세로 분리한다고 알고 있었는데 회원등급 테이블의 경우 1:1 필수 관계로 별도 테이블로 설계가 되어 있는 걸 다른 곳에서 보았다.
1명의 회원이 n개의 로그인정보를 가질 수 있는 것은 사실이다. 그래서 별도의 로그인 테이블로 바꾸었다.
디비 설계시 실제로 만들어질 테이블을 구상하면서 하려고 노력했다. 구상이 잘 안 갈때는 구글 시트에
테이블 하드코딩을 했다.
로그인을 별도의 테이블로 설계한 이유 중 하나는 마지막 로그인 시각이다.
회원이 3개 정도의 계정을 가진다고 했을 때, 그 중 하나는 비활성화 되어 있을 수 있다.
그래서 로그인한 계정별로 마지막 로그인 시각을 별도로 관리해야 한다고 판단해서 분리했다.
컬리패스를 회원에서 관리해야 하나? 하는 궁금증을 빼고는 정리가 한 번 되었다.
