프로젝트 ERD 설계 도중 M:N(다대다) 관계를 표현해야 했는데, 다대다 관계를 ERD에서 어떻게 표현하는지 이번에 처음 알아서 기록하려 한다. 더불어 테이블을 설계하며 고민했던 소셜 계정 메일과 일반 계정 메일의 중복 이슈를 해결한 과정 또한 기록하고자 한다.
이슈
최초로 설계한 유저 테이블은 하나였다.
소셜 로그인 여부 컬럼을 통해 소셜유저와 일반유저를 분리할 수 있다고 생각했지만, 컬럼을 이렇게 설계 했을 때 다음과 같은 문제가 발생한다.
- 일반 유저가 갖고있는 password는 소셜 유저에겐 필요없다(소셜 로그인 비밀번호로 접속하기에 소셜 로그인은 비밀번호를 따로 보유하지 않음)
- 소셜유저만이 필요한 컬럼도 존재하기 때문에, 서로가 서로에게 필요없는 Null 데이터를 보유하게 된다.
따라서 각자가 필요없는 컬럼을 보유한 채로 테이블을 공유해야 하기 때문에 성능과 가독성 면에서 비효율적이라 판단하고, 분리하였다.
1. 테이블 분리
그래서 소셜 유저와 일반 유저가 공통으로 갖고 있는 컬럼은 User테이블에서 관리하고, 그 이외에 각자의 컬럼 값은 각자의 테이블을 생성하여 관리하기로 하였다.
애초에 테이블 분리만 하면 될거라 생각했는데,
id값이 중복되는 이슈도 생각하여야 했다.
위 예시처럼, 각 테이블에서 PK값으로 id를 관리하면, 같은 id 값이지만 그 안의 value가 다른, 어색한 상황이 발생할 수 있다는 것이다.
그래서 우리가 내린 결론은 다음과 같다
- 공통 User 테이블을 하나 두고 일반 유저 테이블과 소셜 유저 테이블을 따로 둬서 공통 user 테이블의 id 값을 참조하도록 한다.
결론적으로 나온 유저 테이블이다.
1대1 연관관계를 맺고, 소셜유저 테이블과 일반 유저 테이블의 id값을 user 테이블의 id를 참조하여 FK값이자 PK값으로 두었다.
이렇게 되면 별도로 두 테이블에서 개별의 PK(id)값을 가지지 않고, User 테이블의 id를 따르므로 id 값이 Unique해지게 된다.
추가적인 이슈
위 테이블을 설계하며 또 고민했던 부분이 있었다.
소셜계정의 이메일과 일반 계정의 이메일이 중복되면 어떡하냐?
기존의 소셜 계정에서 a@example.com의 이메일을 이용하여 가입하고
또 일반 가입으로 a@example.com의 이메일을 이용하여 가입한다면?
위 테이블에선 소셜 로그인의 이메일과 일반 유저의 이메일을 중복체크할 수 있는 수단이 없었다.
따라서 비밀번호 재설정 시 이메일 주소를 통해 비밀번호 재설정 링크를 보내준다던가의 상황에서 모호해지고, 무엇보다 유저의 흐름 자체에서 같은 이메일로 두번 가입이 된다는 것 자체가 어색하다는 의견이었다.
그래서 결론적으로
이메일 또한 공통 유저 컬럼으로 분류하였다.
이를 통해 중복된 이메일로 회원가입 하는 것을 방지하여 어색한 흐름을 방지할 수 있었다.
느낀 점
역시 ERD 같은 설계는 말이 많이 나오고 논점이 많을 수 밖에 없다고 느꼈다.
하지만, 다수의 인원이 설계를 함께 진행하며 최대한 상대방의 의견을 납득 하려 노력하고, 상대방의 의견에 반대한다면 그에 맞는 의견을 제시하여야 건강한 토의가 진행될 수 있다는 걸 다시 한번 느꼈다.
또한 테이블을 설계할 때 테이블을 여러 테이블로 분리하는 것이나, FK 자체를 PK로 쓰는 기법을 통해 고유성을 지키는 방법을 배울 수 있었다.
다시 제자리로 변경
유저 테이블을 다시 하나로 합치게 되었다 !
컨설턴트님과 회의를 진행한 후 피드백을 들었던 내용이다.
- 그냥 Nullable로 두고 하나의 테이블에서 관리하는게 더 편할것이다.
- 추후 유저 테이블의 연산과 소셜유저와 일반유저를 통합해서 관리할떄 불편해지는 부분이 있을 것이다.
결국 택1인데
- 유저를 통합해서 볼 때 join연산이 필요해 불편해 지더라도 Null 데이터를 허용하지 않는 방향으로 갈 것이냐(분리)
- 유저를 통합 관리할때 편하게 한 테이블에 몰아넣고 Nullable로 데이터를 구분해서 둘거냐(통합)
분리 할 만큼, 많이 분리되어있지도 않고, 통합했을때의 장점이 조금 더 크다고 판단하여 다시 통합하였다 !
