데이터베이스 ERD 설계 Ver.1

전체 erd

위 사진은 전체적인 ERD 를 설계한 사진이다

이전에 팀프로젝트로 진행하며 같이 설계가 아닌 처음으로 데이터베이스 ERD를 처음부터 끝까지 설계를 해보았다.

.

.

각각의 테이블에 대한 속성과 디폴트값 NULL의 여부를 하나씩 테이블을 설계하며 많은 생각을 거쳐 나온 결과 물이다.

하지만 직접 벡엔드 개발 중 쿼리문을 짜며 데이터를 가져오며 테이블을 수정해야 할것같다.

특히 댓글과 채팅 무엇보다 알람의 관계에 대해 걱정이 많다.

.

.

.

하지만 직접 개발을 하며 피드백을 거치는 경험은 필수불가결하다 생각을 했으며

그런 경험이 더욱 값질 것이라 생각하고 위 사진은 Ver.1 로 설계를 마쳤다.

.

.

.

이제 개별적으로 살펴 보자

첫번째로 대부분의 테이블이 참조하고 있는 유저 테이블이다.

기본적으로 로컬  회원가입과 로그인기능과 인증과 인가를  위해 

아이디를 email로 사용을 하기 위해 이메일 속성을 따로 두었다.

또한 실명을 사용하지 않고 닉네임으로 활동을 하도록 했다.

.

.

또한 학교별 건물별 소통 플랫폼인 만큼 애브리타임 처럼 전국적으로 사용하는 미래를 꿈꾸며 대학교 속성을 추가 하였다.

또한 이후 중고 거래나 단체 주문히 상대방의 노쇼 및 구라핑을 방지하지 위해

사용자의 경도 위도값을 따로 저장하여 학교 전방 1km 이내의 사용자임을 확인하고 하여 추가 하였다.

 

게시판 테이블은 기본적인 제목, 내용, 좋아요 수가 들어가며

익명 기능을 추가 할지말지 고민중이라 우선은 넣어 두었다.

.

.

또한 고민한 부분중 한 부분이 이미지를 처리하는 테이블을 따로 둘까 하다가

우선은 이미지를 하나만 올릴 수 있도록 개발을 진행 할 것이며

1차 배포가 완성되면 여러개의 이미지를 위해 따로 테이블을 뺄까 한다.

.

.

또한 모든 게시물에는 건물을 선택해야한다.

.

.

ß

댓글기능의 경우 대댓글 기능을 고려하느라 많은 레퍼런스와 고민을 해보았다.

.

.

.

크게 두개의 방식이 있는것 같다.

1. 댓글 테이블을 하나로 두고 속성 값에 댓글의 깊이와 댓글의 부모, 자식 속성을 추가 하는 것

2. 댓글과 대댓글 2개의 깊이로 지정한채 각각을 테이블로 만드는것

.

.

결론적으로 나는 2번 방식으로 진행을 하려고 한다.

무엇보다 굳이 무한 대댓글 기능은 오히려 산만하여 서비스 사용시에 가시적 불편함을 줄것 같다고 생각을 하였다.

또한 테이블이 꽤나 늘어났지만 처음 ERD 설계를 통해 개발시 이왕이면 직관적으로 이해에 도움이 된는게

현재의 나한테는 낫다고 생각이 들었기 때문이다.

.

.

.

채팅과 채팅방의 경우 꽤 많은 레퍼런스와 생각을 해 보았지만 아직 확신을 못하겠다.

우선 로그인, 게시판, 댓글 기능을 완성한 후 더 세부적으로 고민을 해보아야 겠다.

.

.

특히 외래키 연결에서 현재 짜놓은 erd가 잘 설계가 되었는지에 대한 불안이 크다.

그렇지만 우선 가장 기본적인 채팅방 제목, 채팅방 활성화 상태와 채팅시 내용 속성은 문제가 없을것같다.

차후 채팅을 읽은지 않읽은지 확인하거나 알림관련해서는 개발을 하며 수정을 해보아야겠다.

 

 

무엇보다 가장 큰 고민이무 문제 덩어리인 알림 테이블이다.

현재 위 사진과 같이 개별적으로 보아서 속성이 3개만 있어서 복잡해 보이진 않지만

외래키 연결과 테이블간의 관계를 어떻게 해야할지가 관건인 테이블이라 아직도 뚝배기가 아프다..

.

.

.

우선은 알람 기능은 최후로 다른 게시판, 댓글, 채팅 기능이 끝난후 결국은 수정을 해야 할 것같다.

.

.

다른 레퍼런스를 공부해본 결과

각자의 프로젝트에서 원하고자하는 알림 범위에 따라 속성과 테이블간의 관계가 달라지는 것 같다.

우선 알람 기능은 공부할수록 세밀하게 설계하는데는 끝이 없다고 생각이 될 정도로 복잡하다.

.

.

결국 한 게시물에 관련된 모든 사용자의 Idx 를 뽑거나 한 채팅방에 속한 모든 사용자의 Idx 를 

참조하여 알림을 보내는 방식을 택하고 설계를 마치도록 하였다.

 

.

.

.

 

총평

우선 처음 ERD를 설계하며 생각 보다 고려할 요소가 많다는것을 생각 하게 되었다.

또한 나의 이번 버전의 ERD 설계는 가능한 테이블을 많이 쪼개었다.

가장 걱정이 되는 바는 백엔드 개발시 데이터를 쿼리하는 과정에서 join을 2중 3 중까지 하게 되어

조회시에 많은 시간이 소요되어 사용자가 사용에 불편을 느낄 수 있다는 점이다.

'

'

'

초기 데이터가 많이 없을 때는 모르게만 사용자 100명 정도가 한달 정도만 사용하여도

너무 많은 데이터가 싸여 이후 딜레이 시간이 많이 걸릴 수도 있다 현재 생각한다.

.

.

하지만 위와 같은 경험은 내가 오히려 원한 경험이다.

어떻게 진행될지 모르지만 그때마다 만나는 트러블 슈팅을 최대한 몸으로 느끼며 해결해보는 경험을 얻어 보자 !