플레이 리스트 아이템 조회 쿼리 로직 단순화

📝Description

• 원래는 DTO 조회였던 QueryDSL 코드를 단순 엔티티 조회로 변경
• 음악도 같이 조회해야 하므로 fetch join 활용
• 기존 삭제된 음악 필터링(deleted_at is null) 은 join의 on 절에서 where 절로 옮김 (fetch join 과 on 절은 같이 사용 불가)

❓Reason

• DTO 조회는 Playlist 조회와 같이 통계 함수가 쿼리에 들어가는 경우처럼 좀 더 복잡하거나 엔티티의 컬럼 이외의 값(통계 결과 등) 이 같이 조회 될 수 있는 등 fetch join 만으로는 해결하기 어려울 때 사용
• 근데 플레이 리스트 아이템 조회는 단순히 아이템과 그 아이템이 가지고 있는 음악을 리스트로 조회하는 로직
• 그래서 굳이 DTO 까지 써가며 유지보수를 더 복잡하게 만들 이유가 없고 그냥 엔티티 조회 + fetch join 정도로만 최적화 하는게 적당하다고 판단
• 단순화로 인해 음악의 모든 컬럼이 select 되긴 하지만 어짜피 API 용 DTO가 있기 때문에 필요없는 값은 필터링 되고, select 되는 컬럼이 좀 많다고 큰 이슈는 왠만하면 안생김
• 또 기존 삭제된 음악 필터링 조건이 on 절에서 where 절로 옮겨졌지만 left join 이 아닌 inner join 으로 음악을 가져오기 때문에 문제 없음

✨Conclusion

• 원래는 별 생각없이 QueryDSL 사용 시 DTO 조회를 기본으로 사용했지만, 여러 트레이드 오프를 다시 생각해보며 조금 더 설계적으로 최적화
• 앞으로 로직을 구현할 때는 극한으로 최적화 하려는 습관은 조금 자제하고 여러 관점에서 더 봐야겠다