게시판 서비스 고도화 작업을 하는 과정에서 추가 도메인을 설계하는 부분을 진행할 수 있었다. 대댓글 기능 추가, 해시태그 개선 등 고도화 작업을 진행하는데 있어서 기존에 만들어둔 도메인에 변화가 생기기 때문에 고려할 부분이 다소 많이 생기게 되었다. 따라서, 이전에 작성한 ERD를 보면서 새롭게 작성하는 시간을 가졌는데, 대표적으로 가장 큰 변화는 게시글 테이블에 단일 필드로 존재하였던 해시태그를 없애고, 새로운 해시태그 테이블을 생성하여 그곳에서 관리하는 부분이다. 즉, 하나의 게시글에 어떤 해시태그가 포함되었는지 알기 위해서는, 게시글 테이블만 보아서는 안되고, 해시태그 테이블에도 접근하여 정보를 취합해야 하는 부분이 생겼다. 기획 단계에서의 설계를 살펴보면, 하나의 게시글은 여러개의 해시태그를 가질 수 있고, 하나의 해시태그는 여러개의 게시글에 등록될 수 있다. 즉, 게시글과 해시태그의 관계는 다대다이므로, 이러한 부분을 고려하여 ERD를 새롭게 작성하고, 도메인을 변경하는 부분이 필요하였다. 강의에서는 다대다 매핑 테이블을 새롭게 생성하여 해당 부분을 관리하도록 진행하였는데, 실제로 다대다 관계를 쓰지 말라고 하는 여러 블로그 의견이 있는 만큼 해당 내용에 대해 깊이 있게 알아봐야겠다는 생각이 들었다. 실제로 현재 시스템 운영 업무를 진행하고 있는 회사에서도 다대다 관계의 매핑 테이블을 만들어서 데이터를 관리하는 방식을 채택하고 있는데, 실무적인 관점에서는 확실히 이러한 방식이 많이 사용되고 있다는 점을 느끼게 되었다. 다대다 매핑 관계를 쓰게 되면, 가장 큰 단점은 JPA가 해당 테이블을 자바 소스 없이 자동으로 만들어준다는 점에서, 인프라팀과 소프트웨어 개발팀 간 정보의 공유가 부족할 시, 매핑 테이블을 고려하지 못한 채 업무를 진행하는 등 관리하기 어렵다는 점이 있다. 또한, 해당 매핑 테이블은 JPA가 자동으로 생성해주기 때문에, 테이블 내에 추가적인 수정을 하거나, 변경을 하고 싶을 때, 개별적으로 관리할 수 어렵다는 단점 또한 있다. 이러한 부분을 고려하여, 다대다 관계의 데이터를 다룰 때, 팀 내에서 어떠한 방식을 채택하는 것이 좋을지 진지하게 고민해볼 필요가 있는 것 같다.
패스트캠퍼스 [직장인 실무교육]
프로그래밍, 영상편집, UX/UI, 마케팅, 데이터 분석, 엑셀강의, The RED, 국비지원, 기업교육, 서비스 제공.
fastcampus.co.kr
본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.