Trouble Shooting/Data API (4) 썸네일형 리스트형 QueryDSL - 3중 Join N+1 해결 보통 두개의 테이블에서 N+1 문제 발생시 Left Join을 통해서 해결을 한다. API 제작 중에 3개의 테이블을 Left Join해서 N+1문제를 해결하고자 하였으나 쿼리문을 3개 발생시켜 이를 해결해서 쿼리문의 양을 줄이고 DB 서버에 부하를 줄이고자 하였다. API API를 간단하게 설명하면 사용자가 음식점에서 예약을 하면 예약이 DB에 영속화 된다. 이 후 정보 요청시 예약만한 경우에는 예약 정보만을 출력하지만 사용자가 해당 예약정보에 맞는 주문까지 하고 정보 요청시 총 3가지의 정보가 들어가게 된다. 기존 코드 해당 코드처럼 작성시 총 3개의 쿼리문이 발생한다 N+1문제는 발생하지 않지만 두개의 left join이 제대로 처리되지 않는다. 예를 들어, 1번 테이블과 2번테이블은 1대1, 2번.. Query DSL, Entity대신 DTO로 받기 Querydsl 사용시 Entity가 아닌 DTO로 받는 방법을 간단하게 정리해보고자 한다. API - 작성하고자 하는 API를 설명해보자면 가게마다 운영시간 정보가 있다. 가게 이름, 가게 쉬는 시간 리스트, 가게 시작시간, 가게 종료 시간, 예약 다시 받는 시간 간격(예를 들어, 한시간 뒤에 해당 테이블을 다시 받겠다.) - 여기서 가게 쉬는 시간은 여러 시간이 존재할 수 있으므로 다른 테이블을 통해 조인 관계로 설정을 해두었다. - 이제 API에서 클라이언트가 받고싶은 데이터는 해당 데이터 전체이다. 따라서 Entity보단 입력 받은 데이터를 그대로 전달해줄 수 있는 DTO를 통해 데이터를 전달하는게 더 효율적이다. StoreTimeInfoDTO result = queryFactory .select.. Querydsl 적용과 고찰 이번에 진행하고 있는 프로젝트에서 querydsl을 적용해보고 있다. 발생하는 고찰들에 대해서 정리하고자 한다. 1. Query DSL을 통해 불필요한 데이터 제거 및 DB내의 데이터 순환 효율성 처리 로그인 API - 로그인의 기존 로직은 해당 아이디에 맞는 Entity를 찾고 해당 엔터티가 null이면 아이디가 존재하지 않음으로 보고 오류를 발생시킨다. 그리고 기존의 받은 비밀번호와 해당 아이디 엔터티에 해당하는 비밀번호가 일치하지 않으면 또 오류를 발생시킨다. - 고찰 : querydsl의 장점인 가독성 부분에 대해서는 문제가 없어보인다. findByUserId라는 메서드는 충분히 이해가 가능하다. 다만, 필요없는 데이터도 가져온다. 현재 아래에서 필요한 데이터는 비밀번호 데이터 뿐인데, Entit.. SELECT + JOIN 개선에 대한 고찰 1. 문제 인식 단계 : 문제가 발생했음을 인식하고 해당 문제를 명확하게 기술한다. 1-1. API 설명 현재, 하나의 API를 제작 중에 있다. API : 가게이름을 받고, 그 가게의 쉬는날을 반환한다. Entity는 아래와 같다. 1. StoreRestDaysEntity (부모 엔터티) - Days Id (Identification) - Store Name - Set - Created At - Updated At 2. StoreRestDaysMapEntity (자식 엔터티) - Day Id (Identification) - StoreRestDayMapEntity - (Days Id (FK)) - Date 위의 엔터티에서 부모 엔터티는 StoreRestDaysEntity이고 자식 엔터티는 StoreRe.. 이전 1 다음
