괜찮은 ERD 설계 방식일까요?

Question

안녕하세요 취업 준비 중인 갓 대학 졸업한 전공생입니다. 포트폴리오를 작성하며 이전에 제가 만든 프로젝트를 마이그레이션 하고있습니다. 정확한 방향성은 있지 않지만 제 역량을 키우고자 하는 마음으로 시작하였는데, 이전에 작성했던 ERD설계 방식에 의문이 생겨 이렇게 글을 작성하였습니다.프로젝트의 mvp는 반려견 비대면 진료 시스템입니다.원래 수의사, 반려견주로 Entity가 나눠져 있었습니다. 수의사, 반려견주에서 보안 및 개인정보에 대한 부분이 중복된다 생각하여 정규화하는 목적으로 User라는 테이블을 분리하였습니다.User는 수의사 혹은 반려견주와 1:1매핑이 되며, 이메일 비밀번호, refresh token등 수의사와 반려견주에 공통으로 저장되던 부분을 저장합니다.위와 같은 설계의 방식이 올바른 것일까요? 일반적으로 작성하던 것과는 사뭇 다른 모양새라서, 면접 때 사용을 할 경우 감점이 될까하여 여쭙어봅니다

장독깨기 · Accepted Answer

구조적으로 문제 될 건 없어 보입니다.조금 이상한 부분만 말씀드려보면,id 부여 하는 부분이 좀 이상하긴 합니다.사용자와 수의사가 1:1 관계라 했고, 실제로 그렇게 하는 것이 맞습니다.근데, 수의사 아이디를 별도로 부여하면, 여러 수의사 아이디에 동일한 사용자 아이디 매핑이 가능해집니다.이렇게 되면 1:1 관계가 되는 것이 아니겠죠.이걸 막으려면 수의사 테이블의 사용자 아이디를 유니크 제약 걸면 되긴 합니다만,그냥 동일한 사용자 아이디를 수의사 아이디로 사용하면 됩니다.즉, 사용자 테이블의 PK 를 외래키로 수의사 테이블의 PK 로 사용하면 됩니다.이렇게 하면 자연스럽게 1:1 관계가 성립이 됩니다.이 외에도 아이디 부여하는 부분들이 필요없어 보이는 것도 있고,가령, 팔로우 같은 경우 팔로우 아이디를 별도로 둘 필요가 없어 보이구요,굳이 별도로 두려면, 수의사 아이디와 견주 아이디를 유니크 제약 걸어야 합니다.그냥, 수의사, 견주 아이디를 복합키로 PK 걸면 무난해 보입니다.또한, ERD 편집 툴 문제인진 모르겠지만,테이블 전체에 걸쳐 아이디가 전부 AUTO_INCREMENT 로 되어 있는데요,이 부분 완전 이상합니다. 정리하는게 좋겠습니다.크게 지적할게 별로 없네요, 전체적으로 잘 하신거 같습니다. :)마지막으로, https://www.erdspace.com ERD TOOL 인데요, 여기 한번 이용해보세요.가독성 좀 더 좋을 겁니다.관계선에서 식별, 비식별 등 여러가지 옵션을 제공합니다.테이블이 좀 많아지면 관계선이 좀 복잡해져서 어수선해지는데요,관계선 위치를 조정할 수 있어, 보기 좋게 깔끔하게 정리할 수 있습니다.이 외에도 여러 부가기능들이 있으니 한 번 이용해보세요. :)

kenu,전독시 · Answer

데이터 적으면 크게 차이 안납니다.돌아가게 먼저 만드시고, 데이터 보면서 리팩터링 하시는 것을 추천합니다.

엡실론 · Answer

이상한 방식은 아니고 P of EAA에 나오는 Class Table Inheritance 패턴입니다. https://martinfowler.com/eaaCatalog/classTableInheritance.html유저 id를 그냥 수의사 id, 견주 id로 쓰지 않고 따로 만든 까닭이 조금 궁금하긴 하네요. 중요한건 "왜" 이지, 무조건 잘못된 설계는 없습니다. 왜 부분을 위에 잘 적으셨는데, 그걸 면접에서도 잘 설명하시면 됩니다.

괜찮은 ERD 설계 방식일까요?

3개의 답변

기술 목록