[TIL] 최종프로젝트 ERD설계

지금 작성하는 이 글은 해당 웹사이트를 만드는 동안 있던 내용을 기록했다.

https://www.homecomingdaycare.com/

Homecoming Day

 

  1차 설계

최종프로젝트에 진입하면서 백엔드끼리 우선적으로 고려했던 테이블이다.

ERD설계처럼 처음에 코드를 진행했는데 불필요하게 테이블이 많아지는 느낌이 있어서 좀 더 효율적인 설계를 위해 팀원들과 회의를 진행했고, 이 과정에서 articleFlag라는 Column을 넣는 의견이 나왔다.

 

articleFlag를 사용하면 처음 설계했던 DB와 같이 불필요한 자원낭비를 줄일 수 있을 뿐 아니라, 동일 코드를 반복해서 작성할 필요가 없었다.

 

중간 피드백을 받을 당시 상속을 통해 column을 필요한 부분만 받게 하는 방법도 고려해봤다. 하지만 후에 column이 추가되거나 다른 테이블이 추가되며 기능을 추가할 때 DB연관 관계에 대한 부분까지 고려하여 상속이 아닌 하나의 테이블에서 구분자를 통해 데이터를 넘겨주기로 결정했다

 

 

 

  2차 설계

DB 설계를 변경한 뒤에 calendar에 대한 Column을 구성했다.

calendar는 HomecomingDay의 만남일정의 테이블명이다.

 

articleFlag를 통해 , @Pathvariable로 구분자를 두어 게시물의 형식을 구분하고자 했다.

Dto를 이용하여 효율적으로 정보를 내줄 수 있었기에 하나의 테이블 안에서 수행할 수 있었다.

사진과 같이 Frontend에서 @GetMapping을 통해  EX) https://www.homecomingdaycare.com/calendar 와 같이 값을 내주면 Backend에서는 articleFlag를 이용한 if문으로 형식을 다르게 구분했다. 

187번과 208번을 통해 들어가면 Dto를 통한 반환값이 다르게 나오게 된다.

 

후에는 테이블 설계를 봤을 때 직관적인 column명을 표기하기 위해 column명을 수정했다.

 

 

   3차설계 최종

팀프로젝트라는 명칭답게 해당 파트를 맡은 Backend/Frontend 분들끼리 충분한 대화를 나눈 뒤에 여러 기능을 붙였다.

2차 설계에서 크게 달라진 부분들은 기능적인 부분은 당연히 훨씬 많아졌다.

위에서 언급했듯이 한눈에 봐도 해당  column이 이런 역할을 한다고 알려주고 싶었기 때문에 mDate/mTime/place라는 이름을 calendarDate/calendarTime/calendarLocation으로 바꿔주었다.

 

HomecomingDay 서비스는 회원가입 후 첫 로그인 시에 받는 학교정보에 따라 학교 별로 나뉘게 한다.

이 과정에서 기존에는 오픈 API를 통한 학교정보를 받아왔으나 현재는 Scheduler를 통해 주기적으로 학교정보를 업데이트 하여 데이터의 무결성을 유지하고자 했다.

 

다음에 한 번 더 프로젝트를 할 기회가 생긴다면 연관관계 부분을 고려하여 DB를 더욱 효율적으로 짤 수 있을 것 같다.

길다면 길고 짧다면 짧은 6주동안 많이 배웠다. 인간적으로도 프로그래밍적으로도.

좋은 팀원들 덕분에 많이 성장할 수 있었다.