개발자

SQL에서 JOIN은 지양해야하나요?

2023년 03월 02일조회 431

안녕하세요, 최근에 어떤 블로그를 읽다가 클라이언트에 직접적으로 데이터를 뿌려주는 데이터베이스의 경우 JOIN을 지양하는게 좋다 라는 취지의 글을 보았는데요. 이게 현업에서도 그런지 궁금합니다. 물론 상황에 따라 다르겠지만, 일반적으로 조회가 잦은 데이터의 경우 JOIN 쿼리문을 잘 안쓰나요?

이 질문이 도움이 되었나요?
'추천해요' 버튼을 누르면 좋은 질문이 더 많은 사람에게 노출될 수 있어요. '보충이 필요해요' 버튼을 누르면 질문자에게 질문 내용 보충을 요청하는 알림이 가요.
profile picture
익명님의 질문

답변 1

인기 답변

현구막님의 프로필 사진

그럴수도 있고, 아닐 수도 있다고 생각합니다. 블로그에서 "클라이언트에 직접적으로 데이터를 뿌려주는 데이터베이스의 경우 JOIN 을 지양하는게 좋다." 라고 이야기한 부분에 대해 제 마음대로 추측을 하자면 아래와 같은 케이스들이 있을 것 같습니다. 1. 클라이언트에게 직접 뿌려진다는 것은 조회 요청이 많다는 뜻이다. DB 연결에 대한 비용조차도 부담이 되는 방대한 트래픽을 가진 시스템이다. 2. 대부분의 경우 JOIN 키워드 부분을 손보면 쿼리 성능이 큰 폭으로 개선된다. 대부분의 슬로우 쿼리는 잘못된 JOIN 키워드로 사용으로 발생한다. 3. CROSS JOIN 을 이야기한다. 카테시안 곱이 발생하는 케이스. 3가지 베이스로 한다면 JOIN 쿼리를 지양하고 다른 해결책을 모색하는 방식으로 더 좋은 시스템을 구성할 수 있을 것 같습니다. 질문자분께서 잘 아시다 싶이 모든 애플리케이션의 시스템 디자인은 비즈니스 특성에 따라 달라집니다. 널리 사용되는 웹 애플리케이션의 경우 CREATE, UPDATE, DELETE(이하 CUD) 작업보다 READ 작업이 더 많이 발생하므로 매번 연관 테이블들을 JOIN 해서 조회 결과를 전달하는 것보다, 미리 조회에 용이한 형태로 준비해둔 후 조회 요청시 준비된 데이터를 반환하는 것이 성능적으로나 DB 관리비용적으로나 유리합니다. 준비 방법으로는 조회용 테이블 분리, 캐싱용 DB 사용 등이 있겠네요. 그러나 조회에 용이한 형태로 시스템을 디자인, 유지보수 하는 것도 비용이고, 그렇게 디자인 된 시스템을 신규 입사자가 이해하는 것 또한 비용이겠죠. 혹은 원본 데이터 테이블에서 CUD 작업이 빈번하게 일어나는 가운데 조회 요청의 실시간성이 중요하다면, 강제로 원본 테이블에서 JOIN 쿼리를 사용할 수 밖에 없기도 할거 같아요. 복잡도와 트래픽이 낮은 시스템에서 굳이 별도로 조회용 시스템을 구축하기보다, 기존 형태에서 JOIN 키워드 하나를 추가하는게 더 좋은(저렴한, 빠른 시간내에 문제를 해결할 수 있는) 방법이 될 수도 있습니다. 때문에 "일반적으로 조회가 잦은 데이터의 경우 JOIN 쿼리문을 잘 안쓰나요?" 질문에는 "그럴 수도 있고, 아닐 수도 있다." 라고 애매한 답변을 드릴 수 밖에 없는 것 같아요.

profile picture

익명

작성자

2023년 03월 06일

오 그렇군요.. 어느 때 JOIN 쿼리를 쓰는 것이 낫고 어느 때 아닌지 상세한 설명 감사합니다!!

지금 가입하면 모든 질문의 답변을 볼 수 있어요!

현직자들의 명쾌한 답변을 얻을 수 있어요.

또는

이미 회원이신가요?

목록으로
키워드로 질문 모아보기

실무, 커리어 고민이 있다면

새로운 질문 올리기

지금 가입하면 모든 질문의 답변을 볼 수 있어요!