JustDoEat
[고민해결] 상품 테이블에 중복을 일부러 곁들인다면 맛있을까? 본문
개요.
API를 만드는 도중, 일어난 고민이다.
상품을 조회하는 로직은 크게 두 가지로 나눌 수 있다.
1. 크게 상품에 대한 간략한 정보들만 보여줌(대표이미지, 제목, 가격, 지역 등등)
2. 상품 상세조회시 간략한 정보에... 상세정보를 곁들인... 상세조회.(상품에 대한 여러 이미지, 상세정보, 후기, 판매자 정보 등)
그래서 결론이 무엇이냐, 상품에 대한 간략한 정보만 가지고 올 때, 이미지를 불러오는 것 때문에 이미지 테이블에 JOIN이 일어나게 된다. 여기서 든 고민은
"굳이 대표이미지 1장만 필요한데 JOIN을 해야하나 ?, 상품이 한 페이지에 10 개식 뜬다고 했을 때 대표이미지를 위해 10번의 JOIN이 일어날 필요가 있나.."
이 문제를 해결하기 위해 했던 고민들.
" one to many 관계를 설정 후 LAZY 로징, 혹은 패치 조인을 해볼까.."
어차피 레이지 로딩을 걸어도 이미지가 필요하다면 N+1 문제가 생기고, 패치조인을 한다 한들 어차피 이미지를 전부 가지고 오는 건 매한가지인 거 같았다.
"이미지 갯수에 제한을 두어서 상품테이블에 각 칼럼을 만들어서 일부러 정규화를 해보지 말까?"
이 생각이 나온 이유는 상품에 대한 이미지가 중복으로 많이 쓰인다면 고려를 해보겠지만. 사용자가 상품 사진을 등록한다 한들 서비스 특성상 이 사진을 또 사용할 일이 많지 않을 거 같았다.
무엇보다 JOIN이 덜 일어나면 좋은게 아닌가?
"그대로 가볼까?, 쿼리문에 LIMIT 1 을 걸어서 딱 한 개만 가지고 올까? image 엔티티에 Boolean isMain 칼럼을 추가해서 해당하는 것만 가지고 올까? "
결론은 중복을 허용을 했다.
위의 고민들을 다 종합해본결과 그냥 상품테이블에 대표이미지 칼럼을 추가하면 되겠다고 생각을 했다.
상품을 등록할때 가장 처음 등록한 사진을 상품테이블에 넣어주고 나머지는 중복을 허용하면서 이미지 테이블에 넣어버리는 것이다.
이렇게 되면 단순 select만 해도 내가 원하는 정보는 모두 뽑을 수 있다는 결론에 도달했다.
상세정보가 필요하다면 그때 Join을 하면 되는 것이고, 단일상품 하나에 대한 Join은 크게 부담이 없을 것 같기도 했기 때문이다.
이건 나만의 생각이니 팀원들에게 설명을 하니 모두 동의를 해주었다!! 이야호
물론 정답이 아닐 수 있다. 나는 개발경력이 많지 않고 경험도 많이 없지만. 현제 내가 할 수 있는 생각 중 최선의 생각이었다고 생각한다.
무조건 정규화가 빡빡하다고 좋은 건 아니라고 배웠다, 서비스 특성상 어느 정도 중복을 허용하는 게 좋을 거 같다면 나쁘지 않은 아이디어인 거 같다!
'Yajoba > Backend' 카테고리의 다른 글
MultipartFile 에서 파일 확장자를 검사 해보자. + 멀티파트에서 @Validated가 안되는 현상 (4) | 2024.11.28 |
---|---|
상품검색 서비스가 언제 확장될지 모른다! 전략패턴(Strategy Pattern)으로 해결해보자 (0) | 2024.11.27 |
팩토리 클래스에 객체 생성에 필요한 서비스를 의존을 받았다. 정답일까 아닐까 (1) | 2024.11.21 |
Data JPA, DTO, Projection 방식중 적합 한 방식은 ? (0) | 2024.10.28 |
[문제해결]카테고리입니다, 셀프조인도 같이 드시면 맛있습니다 (4) | 2024.10.13 |