Hustle #9. Aquery Tool 으로 ERD 모델링하기

안녕하세요, 다람쥐입니다.

이번 포스팅은 ERD 모델링 포스팅입니다.

저번 포스팅까지는 AWS 인프라를 셋팅하거나 간단한 프로젝트 설정을 했습니다.

이제 팀원들 끼리 만나 테이블 설계를 해 볼 차례였어요.

허슬 프로젝트의 규모가 꽤 있어 제대로 된 테이블 모델링이 필요한 상황이었는데요!

 

처음에 만든 것과 다르게 기획이 바뀌어서 테이블이 또 바뀌기도 하고

개발하면서도 테이블이 바뀌기도 했는데요.

이번 포스팅에선 어떻게 설계를 했고 어떻게 수정 이력을 관리했는지 담았습니다.

 

저희... ERD 모델링 해볼까요?

때는 바야흐로 7월달이었어요.

허슬 프로젝트의 피그마를 처음 전달 받았을 때 느꼈던 점은

규모가 꽤 크다, 정도였어요.

적어도 도메인이 네 개 이상이었어서 쉽지 않겠다, 라는 느낌이 들었는데요.

ERD 모델링 하는 것 부터 난관이었어요. 🤣

 

백엔드 프로젝트를 처음 하는 분이 두 분, 구현은 가능한 분이 한 분, 그리고 저 이렇게 있었는데요.

그러다보니 테이블 설계, ERD 모델링을 빠르게 하기가 쉽지 않았었어요.

최대한 각자 짜와보고 통합하는 식으로 진행했었어요.

 

기본적으로 Soft Delete 가 구현될 수 있도록 하고

생성 시각, 업데이트 시각 같은 공통 필드의 이름은 통일하도록 했습니다.

도메인도 많다보니 다른 부분을 짜와보는 걸로 했어요.

처음 다 같이 모였을 때 다음 주 까지 짜와보자! 하고 헤어졌는데요..!

그런데 웬 걸..?

 

그런데 웬 걸..?

각자 다른 어플리케이션을 사용해서 테이블을 설계해왔어요.

저는 MySQL WorkBench, 다른 분은 Aquery Tool, 또 다른 분은 인터넷에서 ERD 무료로 그릴 수 있는 사이트를 참고했어요.

ERD 모델링은 모두 다 함께 봐야 하니 한 곳에 옮기는 게 어떻냐고 물어봤어요.

그랬더니 Aquery Tool 로 하신 분이 자기가 예전에 결제했었다고, 자기걸로 공유하자고 하시더라고요! 🥺

그래서 Aquery Tool 로 통일했습니다.

AQueryTool

다만, Aquery Tool 은 로그인 세션 한 개가 제한이었어요.

한 명이 사용하고 있다면, 누군가는 사용하지 못하고 로그아웃 처리 되어버립니다. 😭

그래서 사용한다면 수시로 저장 버튼을 누르고 누가 사용 중인지 물어보곤 했었어요.

다행히 겹치는 일이 크게 많지는 않았네요.

 

Aquery Tool 을 써보자

Aquery Tool 으로 한 곳에 테이블을 모았어요.

유저부터 대회, 동아리, 학교, 교류전, 커뮤니티 등의 도메인을 한 곳에 모으기 시작했어요.

당연히 처음에는 각기 다른 형식이었지만, 제가 현업에서 테이블을 설계한 경험이 많아서 최종적으로 정리를 했었어요.

 

피그마 화면을 보고 테이블이 문제가 없는지, 누락된 건 없는지 꼼꼼이 확인을 했고

모든 필드를 최대한 통일하면서 ERD 모델링을 했었어요.

Aquery Tool 화면

 

에이쿼리에서 테이블을 만들 수 있고, FK 설정도 하면 화살표로 관계 표시도 시각적으로 보여줘서 좋았어요.

또 Comment 으로 어떤 필드인지 한글로 설명할 수 있는 게 좋았어요.

자주 사용했던 메뉴로는 '모든 테이블 생성 SQL' 과 '이미지 파일로 내보내기' 를 많이 사용했어요.

Aquery 메뉴

모든 테이블 생성 SQL 은, Aquery 에서 설계한 대로 의존관계까지 고려해서 테이블 생성 순서를 맞춘 테이블 생성 SQL 문을 보여줘요.

데이터베이스를 초기 설정할 때 위 SQL 문을 토대로 테이블을 설계했어요.

 

이미지 파일로 내보내기는, AQuery 사이트가 계정 하나만 접속할 수 있어서 저장 용도로 이미지 파일로 다운로드 받았어요.

캔버스에 있는 모든 테이블을 다운로드 받을 수 있습니다.

 

우리 팀이 특별히 신경 썼던 점!

에이쿼리에서 테이블을 만들 때 필드를 통일하게 만드려고 노력했었어요.

첫 번째로 FK 는 PK 다음에 배치했습니다.

PK 이름은 id 로 통일했으며, FK 는 '테이블명(소문자)_id' 으로 통일했습니다.

아래 사진에서 볼 수 있듯이, PK인 'id' 필드 다음에

FK인 'user_id', 'sport_event_id' 를 배치했어요.

두 번째로 시각 필드를 통일했어요.

생성 시각과 수정 시각이 공통적으로 들어가 있습니다.

생성 시각과 수정 시각은 데이터가 처음으로 삽입된 시각이 기입됩니다.

이후 데이터를 수정할 때 마다 수정 시각이 업데이트 됩니다.

세 번째로 Soft Delete 기능을 위한 필드는 'status' 으로 명명했습니다.

Soft Delete 는 데이터를 삭제했지만, 데이터는 그대로 남아있는 걸 의미합니다.

Soft Delete 가 필요한 테이블을 뽑고 그 테이블에서만 'status' 필드를 삽입했어요.

살아있는 'ACTIVE' 값과 삭제된 'INACTIVE' 두 Enum 값으로 관리하고 있습니다.

 

네 번째로 의도적인 반정규화로 테이블을 설계했습니다.

테이블 내에 다른 테이블로 의존성을 분리할 수 있지만, 테이블 수가 많아지고 관리가 힘들어 질 것 같아

최대한 합칠 수 있으면 합쳤습니다.

위의 Competition 테이블에도 필드가 많지만 따로 테이블로 분리하지는 않았습니다.

 

반정규화를 진행한 테이블은 아래 MatchResultPost 테이블에도 적용했습니다.

이전에는 HomeEntryTeam 과 AwayEntryTeam 을 담을 별도의 테이블 MatchResultPostEntryTeam 테이블을 만들었는데요.

MatchResultPost 에는 무조건 두 개의 EntryTeam(참가팀) 이 들어간다는 점에서, 여러 팀이 대결하는 확장 가능성은 없어보여

MatchResultPost 테이블에 하나로 합치는 반정규화를 진행했습니다.

반정규화를 진행한 MatchResultPost

MatchResultPost 의 정보를 한 화면에서 보여줘야 하기에, 'MatchResultPostEntryTeam' 과의 Join 비용도 줄였습니다.

 

테이블을 변경하면 수정 이력은 어떻게 관리하나요?

안타깝게도 Aquery Tool 에서는 수정 이력을 따로 관리해주진 않더군요.

따라서 테이블을 수정할 때 마다 어떻게 수정했는지, 무슨 의도로 수정했는지 알 길이 없었어요.

노션 페이지를 새로 만들어서 기록하기 시작했습니다.

 

팀별 문서 페이지에서 'ERD 업데이트' 페이지를 만들었어오.

수정 내역에 날짜를 기록하고 어떻게 수정 했는지, 무슨 의도로 수정헀는지 적기 시작했어요.

 

마무리

저는 MySQL Workbench 로만 테이블 설계를 해봤었는데

다 같이 Aquery Tool 으로 설계하니깐 재밌었어요.

테이블 설계할 때 많은 이야기를 나눌 수 있어서 뜻 깊었네요!

다음 포스팅은 프로젝트 구조를 한 번 잡아보려고 합니다.

긴 글 읽어주셔서 감사합니다. ☺️