[프로젝트 개선] ERD 설계에서 놓친 부분을 개선해보자!

이번 글에서는 초기 설계 단계에서 놓친 부분에 대해 개선점을 적용해보고자 합니다.

ERD 설계 당시 ( 23년도 2월 기준 ) 기획이 불안정했습니다. MVP가 확정되지 않았고, 사용자의 구분 ( 일반 사용자와 관리자의 구분 )도 명확하지 않았으며 그에 따른 플로우도 명확하지 않았습니다.

기획-디자인-개발이 순차적으로 진행되는 것이 아닌 동시적으로 진행됨에 따라 초기에는 유연하게 변경할 수 있도록 설계하고자 했습니다.

테이블을 디자인하면서 기획팀의 기능 요구사항과 디자인팀의 화면 정의서를 바탕으로 테이블을 구분하고 그에 따라 필요한 데이터를 추출하는 작업을 하였습니다.

설계의 초점을 어떻게 데이터를 묶을 것이며, 관계를 어떻게 정의할 것인가!에 두었습니다.

당시의 ERD 설계 과정에 대한 고민과 결과는 여기 위키 페이지를 확인해주세요.

MVP 기능으로 커뮤니티 서비스를 우선적으로 기획하고 만들기로 하였으며, 게시글과 댓글, 사용자 등의 테이블을 디자인하였습니다.

이때 놓친 포인트는 서비스에 다루는 데이터의 특성을 제대로 파악하지 못했다는 점입니다.

그러면서 마주한 이슈는 "데이터 크기 초과 오류" 였습니다.

여기를 참고해주세요.

게시글의 글자수 제한이 없는 데이터의 특성 상, String의 기본 사이즈인 VARCHAR(255)로 지정할 경우 당연하게 데이터 크기 초과 오류가 발생할 수 밖에 없습니다.

이 이슈를 해결하고자 TEXT 타입으로 지정하였습니다.

이슈를 경험하면서 데이터의 크기가 초과하는 것으로 인한 오류를 막는 것은 캐치하였으나 반대로 불필요하게 공간을 차지하는 데이터에 대해서는 간과하였습니다.

일부 컬럼에 대해서는 데이터 크기를 지정하기도 하였으나, 여전히 불필요하게 큰 사이즈를 지정해둔 컬럼들이 많았습니다.

데이터의 크기 제약을 걸어 일관성을 보장하고, 크기를 미리 예측하여 저장 공간을 효율적으로 사용하고자 데이터의 특성에 따른 크기 제약을 모두 설정하기로 하였습니다.

데이터의 길이를 지정해주지 않는 VARCHAR는 데이터 자체의 값과 함께 길이 정보를 저장하는데 필요한 추가적인 공간을 차지합니다.

이를 위해 아래와 같이 쿼리문으로 컬럼 정보를 변경하였습니다.

alter table house modify city varchar(100);
alter table house modify zip_code varchar(6);

테이블 설계 시, 테이블이 갖는 쓰임이 무엇인지 명확히 파악하고 테이블 간의 관계 정의와 데이터 타입 ( 그리고 크기 )를 잘 정의할 수 있는 능력이 중요함을 느꼈습니다.

서비스의 확장과 데이터의 일관성 보장의 기반이 되기 때문입니다.

Provide feedback