Join을 왜 배우고 왜 써야하는가?

Join이라는 문법은 테이블과 테이블을 붙이는 거다.

거의 모든 쿼리에 join이 들어가고 실무에서 항상 사용한다고 생각해도 된다.

 

만약, 가지고 있는 데이터 중 '오늘의 다짐'을 남긴 회원의 이름을 알아야 한다. 이유는 '오늘의 다짐' 이벤트 당첨자를 선정하여 특정 상품을 기프티콘으로 지급해야 하는 상황이다.

그렇다면 일단 '오늘의 다짐'테이블을 불러와서 살펴보자.

select *
from checkins c

해당 테이블에서는 users_id만 존재하고 name이 존재하지 않는다. 하지만 이름도 알아야 하는걸?.. 어쩌지?

 

반대로 users 테이블에서는?

select *
from users u

해당 유저 id별로 name과 email이 포함되어 있다. 하지만 여기에는 '오늘의 다짐'의 자료가 없다.

 

결국 이 두개의 테이블을 매칭시켜 확인해 봐야한다.

기존 배웠던 것만 활용하려면 checkins 테이블을 보고 user_id를 복사해서 다시 where절로 users테이블에 치고.. 확인하고 해야 하는데, join을 활용한다면 이를 좀 더 손쉽게 할 수 있는 것이다.

 

다음 그림처럼 말이다.

자세히보면 위의 그림처럼 두개의 테이블일 붙여서 '오늘의 다짐'도 바로 볼 수 있고, 해당 user_id를 가지는 회원의 name과 email도 확인할 수 있다.

 

아니 그럼 왜 테이블을 이렇게 나눠 놓는 거야? 그냥 애초부터 이렇게 한번에 묶어 두면 보기 좋지않아?

라는 의문을 가질 수 있다. 이에 대한 답변으로는..

 

테이블은 기본적으로 한 목적에 맞는 것들만 모아 두는 것이 가장 좋다고 한다.

그래서 테이블을 나눠서 보관하는건데, 회원 정보는 회원 정보끼리! 수강정보는 수강정보끼리! 결제정보는 결제정보끼리 등등!! 이게 실제로 웹서비스가 동작하는데 있어서 훨씬 더 편하고, 수정을 함에 있어서 문제가 많이 생기지 않게 하기 위해서라고 한다.

 

그럼 뭘로 이 두개 테이블을 이을 수 있는가?

 

이때 필요한게 기준이다. 예를 들어 실습하고 있는 데이터에서 users테이블에도 user_id가 있고, checkins테이블에도 user_id가 있다.

이 둘을 활용해서 이어주는 것이다. 이런 필드를 두 테이블을 연결시켜주는 열쇠 라는 의미로 'key'라고 부른다.

 

위의 불편한 사항들을 짧은 join 쿼리 한 줄만 더 쓰면, 한번의 쿼리로 이렇게 정보들을 한 눈에 볼 수 있다.