[Day 39] 웹 풀사이클 데브코스 TIL

오늘 배운 내용 📚

• 좋아요 추가, 삭제
• 서브쿼리와 EXISTS를 이용하여 도서조회에 좋아요 여부 확인

추가 정리 내용 📑

• 스칼라 서브쿼리란?
• SQL을 어떻게 사용하면 좋을까?

---

오늘 좋아요를 추가하고 삭제하는 것을 배웠는데 조금 아쉬운 부분이 존재했습니다. 그 이유로는 프런트영역이 같이 진행이 되는 게 아니다 보니 이렇게 추가와 삭제만 할 수 있다고 해서 이미지가 변경이 되고 어떤 원리로 추가와 삭제를 하게 되는 건지 알 수 없었기 때문입니다. 예를 들어서 비활성화된 좋아요를 누르면 POST /likes/:id로 연결이 되고 활성화된 좋아요를 누르면 DELETE /likes/:id로 연결이 되는 건지 이런 설명이 없어서 그냥 '만들어는 놨는데...'로 끝난 거 같아서 아쉬웠습니다.

 

그리고 이제 서브쿼리를 배웠는데요 저는 FROM 단에 서브쿼리를 작성을 했다면 강사님은 SELECT단에 서브쿼리르 작성을 하였습니다. 그렇게 되면서 스칼라 서브쿼리라는 것을 알게 되었는데요. JOIN을 마구잡이로 사용을 하면 당연히 성능저하가 생깁니다. 그렇다면 스칼라 서브쿼리를 많이 사용하게 되면 성능저하가 일어나지 않을까? 해서 찾아보게 되었습니다.

스칼라 서브쿼리도 당연히 성능저하가 일어나지만 필요하다면 사용하는것이 오히려 더 좋을 수 있다는 것을 알게 됐습니다. 그 예시로 도서 전체조회와 도서 개별조회가 있습니다. 

도서 전체조회에 스칼라 서브쿼리를 사용하게 되면 불러오는 전체 행마다 쿼리가 동작을 하는 것입니다. 적은 양의 데이터를 불러오는 작업에는 차이가 나지 않겠지만 데이터가 100개 1000개 를 불러오는 상황이라면 서브쿼리 개수만큼 쿼리가 동작을 하는 거기 때문에 두 배, 세배, 네 배 등등 동작 쿼리수가 많아져 성능에 저하가 발생할 수 있는 것이었습니다. 

도서 개별조회에는 반대로 JOIN으로 묶게 되면 많은 양의 데이터를 일단 한번 다 조회를 하고 WHERE절에서 조건에 맞는 값을 받아오기 때문에 불필요한 작업을 하게 되는데 이때 스칼라 서브쿼리를 작성하게 되면 필요한 데이터들만 모아서 사용하기 때문에 사용을 하는 게 오히려 좋을 수 있습니다.

 

위 예시 처럼 상황에 맞게 쿼리를 작성할 수 있어야 한다는 것을 깨닫는  수업이 됐던 것 같습니다.