22.09.17 TIL 서비스에 맞는 DB 설계란 과연 무엇일까?? 이게 과연 최선일까??

현재 실전프로젝트 기능 서비스는 SNS의 특징들이 있다.

그렇기 때문에   팔로우 상대피드조회 활동게시물 저장등의 관계를 이루고있는 데이터들이 많아

당연하게 DB를 관계형DB인 SQL을 선택하게 되었다. 

 

첫 프로젝트 ERD

그렇기에 처음에 는 관계성DB의 장점이 데이터중복도 없이 각자의 관계를 통해서 현 서비스를 구현하였다.

(누구한테나 그럴싸한 계획은 있다 ㅊ쳐.... 마ㅏ...기...)

 

 

그런데 가장 API요청이 많이가는 요청에 응답값을 주기 위해서는  단순하나의 테이블이 필요한게 아니라 

메인인 todos테이블과 user,comment,challengTodo테이블의 데이터를 전부 가져와야

요구된 응답값을 줄수있게 되었다.....

간단해 보이는 응답값처럼보이지만 3개의 테이블 조인이 필요한상황/.

그결과는 코드 복잡성을 높게 하였고...코드를 짜면서도 수많은 map함수 + findAll;..

과연 이렇게 하는게 맞나라는 의문과.. 

설계에 대한 의심을 하게되었다...결국 백엔드 팀원분이랑이야기를 통해

우리 현재서비스에 맞는 DB설계를 해보고 

효율적인 결과가 나오는것으로 하자 이야기를 하였고 우리의 가설이 맞을수 있게 같이 의논을 하여 DB를 재설계하였다.

서비스의 본질에 맞춰서 DB 계획

이야기를 하면서 비록 관계형 DB이지만 서비스의 본질에 맞지않다면 독립적인데이터로 구현을 하였고

관계가 정말 도움이될만한DB끼리만 관계설정을 하여 현 서비스 구현에 사용을 하였다.

 

그렇게 완료를 하고 난 후에는 DB에 더미 데이터를 입력을 동일하게 한후 속도를 비교해보았다.

 

1번째 안이 기존 DB 설계안을 따라서 진행을 한 결과이며(119ms)

2번째 안이 의논을 통해서 만든 DB 설계안을 적용하여 만들어낸 결과이다.(39ms)

 

물론 위 결과값이 단순 DB 설계 때문만이 아니라 어떤 코드 들이 어떻게 쓰였나에 따라서 값이 변할수도 있지만

어쨌든 이러한 고민들을 했다는것 자체와  그 결과를 입증해내려고 했던 과정들이 좋았었다.

 

결과가 우리 가 생각을 하였던것과 달랐더라도 유익헀던 하루라고 생각한다.