Item 엔티티와 이를 상속받는 Book, Artwork 엔티티를 만들었다. 그 다음에는 이를 조인 전략으로 할지, 단일 테이블 전략으로 할지 고민이었다. 처음에는 조인 전략(@Inheritance(strategy = InheritanceType.JOINED))으로 하려고 했었는데, 왜냐하면 단일 테이블 전략은 테이블이 너무 커지면 성능저하가 있지 않을까 하는 우려가 있었기 때문이다. 이는 테이블의 크기가 어느정도여야 과한 건지에 대한 기준이 불명확하기도 했고, 아이템에 대한 적절한 유지보수를 위해서는 조인 전략을 통해 엔티티별로 분리해서 관리하는 게 코드 상으로 깨끗할 것이라는 생각, 그리고 현재는 크지 않은 서비스를 개발하고 있지만 확장성을 염두하고 있기 때문에 내린 판단이었다.
그러나 조인 전략을 사용하게 되면 각 아이템 카테고리가 늘어날 때마다 엔티티는 추가되고 그에 따라 별도의 리포지토리들도 각각 생성해야 한다는 지점에서 역시 유지보수나 관리가 힘들어질 것이며, 전체 아이템을 조회하려고 하면 하나의 아이템 리포지토리가 아닌 엔티티 각각의 리포지토리를 모두 조회해야 한다는 점에서도 굉장히 비효율적이게 된다. 그리고 확장성을 고려한다면 현 단계에서는 단일 테이블 전략으로 가되, 테이블이 커졌을 때에는 파티셔닝이나 샤딩을 하면 된다. 구조 변경이나 마이그레이션을 대비해서 단일 테이블 전략이 더 적절하기 때문이다.
인강 자료의 ERD 설계도를 보면 언뜻 이해되는 것 같다가도, 막상 엔티티를 작성하려고 하면 감이 잘 오지 않고, 강의를 다시 들어봐도 이해에 한계가 온다. 그런 부분을 몇가지 포인트로 나눠보면 다음과 같다.
@ManyToOne, @OneToMany가 각각 어느 쪽에 붙어야하는지cascade 옵션은 어느 쪽에 붙여야 하는지@ManyToMany는 어떻게 다뤄져야 하는지4번의 경우 카테고리 엔티티에 실제 데이터를 저장할 경우 CategoryItem 중간 엔티티를 두어서 연결하면 된다는 걸 이해했지만, 여전히 1~3번은 보고 또 봐도 헷갈리기만 하고 있다. 중간 엔티티를 만드는 것도 기존 코드를 참고는 하지만 매핑 방식을 어떻게 해야하는지 잘 모르고 있는 상태이다.
이렇게 아주 기초적인 부분부터 기술부채가 쌓여가고 있는 상황이지만, 구현 기간도 계획한 시간을 한참 지나고 있는 상황이다보니 주문 서비스 개발까지 마친 다음 시간 봐서 위 내용에 대해 정리하던지 할 수 있을 것 같다.
테이블 매핑 문제를 해소하기 위해 자료들을 찾아보던 중에 '연관관계 편의 메서드'라는 것에 대해 알게 되었다. 분명 인강을 통해서도 들었던 내용일텐데, 이번 기회에서야 새롭게 알아가는 느낌이다. 아직 익숙하지는 않지만, 양방향 연관관계에서 데이터베이스에서의 설정과 별개로 객체의 양방향 연관관계를 설정하기 위해 작성한다고 한다. 다음 링크 내가 JPA 연관 관계 편의 메서드를 작성했던 이유를 참고했다.
취업 불경기인만큼 마음이 조급해질 수밖에 없지만, 하나를 하더라도 제대로 해야한다는 부분에서는 차근차근 나아가야 한다는 마인드도 당연히 중요하다. 그런 의미에서 켄트 벡 저 <테스트 주도 개발> 책을 샀다. 사실 이번 프로젝트를 통해 테스트 코드 작성하는 습관과 요령을 익히는 것도 하나의 목표였기 때문이다. 아직은 DB에 데이터가 제대로 저장되는지 같은 용도로만 사용하는데, 짬짬이 이 책을 공부하면서 더 좋은 테스트 코드와 개발 실력에 성장이 있길 기대한다.
아이템 서비스 구현이 기존 계획 기간을 초과하고 있다보니, 프로젝트 완성에 있어서도 상당한 지연이 있을 것으로 예측한다. 그런 점에서 취업을 목표로 했던 5월보다 취업준비 기간이 훨씬 더 길어질 수 있다는 것을 염두하게 되는 상황이다. 그만큼 재정 상황이 계속 쪼들리게 되고 몸과 마음도 많이 지쳐간다. 이런 상황을 어떻게 돌파해야할지 뚜렷한 답을 찾기는 어렵지만, 이런 내 상태를 계속 관리하고 모니터링하는 수밖에는 없다.