SQL Join (1) (완)

https://opentutorials.org/course/3884

SQL Join - 생활코딩

======================================

@1.수업 소개

 

join : RDB에서 테이블과 테이블의 관계를 이용해 새로운 테이블을 만들어내는 테크닉

 

여러개의 테이블을 묶어서 하나의 테이블로 만드는 마법

 = 여러개의 표로 분산된 정보를 결합해서 하나의 단일한 표로 만드는 기술

 

1974년부터 지금까지 정보를 저장하고 처리하는 시스템의 절대강자 RDB, 가장 중요한 기능이 JOIN

링크가 없다면 웹이 아니듯이 JOIN이 없다면 RDB가 아니다.

 

이 수업은 아래와 같은 내용을 다루고 있습니다.

• 테이블을 분리하는 법
• 분리 된 테이블을 합성해서 하나의 테이블로 만드는 법 (join)
• join의 종류와 사용법 --상황별로 어울리는 join있다
  • inner join
  • left outer join, right outer join
  • full outer join

아래 내용은 다루고 있지 않습니다.  --이런게 있긴 하다는 거겠지

• 데이터베이스 제품별로 join의 내부적인 동작방법
• join 성능을 향상시키는 방법

 

sql-joins.leopard.in.ua

 

저 사이트에서 연습결과와 연습장을 제공한다

 

 

======================================

@2.테이블 쪼개기

http://bit.ly/sql-join-exec

여기서 따라해볼 수 있게 해놨음

설명은 https://youtu.be/yCbJ1D1Ylik?si=YoXViCWhbsL1WCf3

수정하려면 로그인하고 File - Make a Copy(이러면 복제되고 내것이 됨. 마음대로 수정 가능)

 

이 표는 어떤 문제점이나 아쉬운 점들이 있다

 

1.

일단 1, 3의 내용이 중복

 

*SW를 만드는 과정에서 그게 무엇이건 데이터든 코드든 중복이 발생하면 안좋은 징후다 = 개선할 점이 있다

 

행이 1억개고 천만개가 중복된다면?

 - 데이터 용량을 엄청 차지

 - seoul에 살다가 jeju로 이사하면 천만개를 고쳐야함

 - egoing이 동명이인으로 여러명이면? 이름이 egoing이라는 이유만으로 jeju로 바뀜 --PK를 써야겠네

 

 => 중복을 제거해야해

 

2.

topic이라는 테이블 하나만 운영해. 글에 대한 설명임

우리가 만드려는 시스템에 comment(댓글)도 있다면

 

comment는 제목이 없으니까 (▽이런식으로 판단하는군)

이러면 여기서 또 중복이 발생함ㅋㅋ 극단적으로 공감하기, 천개고, 그걸 수정할 일이 생긴다면?

 

선배들이 이런걸 겪었을거고, 선배중 일을 잘 하는 사람은 어떤 방법으로 해결을 했을 것

저자에 대한 정보를 별도의 표로 쪼개는 것!

그리고 topic에 author_id라는걸 추가, 저자의 아이디, 

오른쪽 테이블에 저자에 대한 정보가 존재.

왼쪽 테이블엔 저자를 식별하는 저자테이블의 주키, PK값만을 기록함. FK라고 한다.

이렇게 하면 중복이 제거됨. 수정도 topic이 1억개여도 오른쪽 테이블의 하나만 바꿔주면 됨.

 

또 직업에 대한 소개부분이 중복이네?

마찬가지로

그리고 profile_id값을 주면 됨.

 

표를 분산하는 걸 통해서 중복을 줄일 수 있다.

 

RDB를 최초로 만든 사람이 한 말, 표를 만들 때 지침으로 삼아야 한 말, 모든 표는 하나의 테마만 가져야 한다.

어떻게 하나의 주제를 찾느냐? : 쉽지 않음

그리고 꼭 합쳐져 있는게(왼쪽위의 맨처음 표) 꼭 나쁘다고 할 수도 없음.

다만 합쳤을 때 중복이 발생할 수 있고, 또 합쳐진 정보가 다른 테이블에서도 사용될 수 있고.. 이런 징후들이 보인다면 누군가를 분가시킬 타이밍이라는것.

좋은면(보기가 편하다)이 있고, 안 좋은 면(수정하기가 나쁘다)이 있다. 읽기가 좋고, 쓰기가 나쁘다, trade off가 존재

나눠져있는 표는 장단점이 반대

 

▽내 직관 : 표를 나눈 것은, FK들이 하나의 PK를, 한 곳을 가리킨다고 보면 됨

 

여기서 장점만 가진 환상을 만들어내는 것이 공학의 목표.미학.보람 = 바로 RDB의 JOIN!

 

======================================

@3.JOIN 실습준비

이전까지 좋은 부품을 만드는법 = 쪼개는 법

쪼개면 다시 결합하는 걸 통해서 완전히 새로운걸 창조할 수 있다.

이제 천재적인 선배들이 어떻게 해결했는지

 

무언가를 생산한다 = 결국 쪼개고 다른 방법으로 다시 붙이고 하는 과정이라고 할 수 있다

 

쪼갠 표를 어떻게 JOIN을 통해 합성하는가, 마치 쪼개기전의 상태

 

https://sql-joins.leopard.in.ua 

SQL Joins Visualizer

A, B두개의 표를 결합할 때 생길 수 있는 경우의 수를 벤다이어그램으로 표현하고 있음, 그 경우는 어떠어떠하게 코딩하라고 SQL을 보여줌

 

A와 B 모두에 존재하는 정보로 새로운 표를 만들 땐

그리고 그땐 INNER JOIN이라는 굉장히 중요한 JOIN을 씀

 

 : A엔 존재하고, B에는 존재 안하는것도 출력한다 --설명은 구체적으로 살펴봐야 명확해짐

이런 경우엔 LEFT JOIN(정말 중요)을 쓴다.

 

 : 두 표 다에 있는것과 한쪽에만 잇는 정보도 새로운 표로 만들어낸다

FULL OUTER JOIN(안 중요한데 훨씬 어려워)

 

 

강의자료에 테이블 생성코드 다 있다

 

======================================

@4.LEFT JOIN (= LEFT OUTER JOIN)

가장 인기있는 JOIN

양쪽 둘다에 있는 정보 + 왼쪽에만 있는 정보

이 2개를 출력하는 것

 

보통 우리가 양쪽 모두에 있는 정보를 필요로 한다기 보다는 어떤 특정한 표 A를 기준으로 정보를 가져올 때

당연히 A에만 있는 정보는 가져와야 할 것이고, B에는 없는 정보도 가져와야 하는 경우가 많을 것, 이때는 NULL로 표현

 

특이점이 있는 행들이 있음. --이게 바로 위의 한쪽에 없는 애들 구분하는 것, 포인트가 이거였구나...몰랐다..

- topic테이블의 author_id가 NULL : author에 대한 정보가 필요가 없다. 익명으로 작성한 글일 수 있는 등..

- author테이블의 3번 blackdew는 topic테이블상에선 발견되지 않는다.

 : 왼쪽의 4행은 오른쪽에 존재하지 않는다

 : 오른쪽의 3번행은 왼쪽에서 사용되고 있지 않다.

이런 경우 JOIN하면 LEFT JOIN / INNER JOIN / OUTER JOIN 에 따라 결과가 미묘하게 달라진다. -> LEFT = OUTER라면서요?

 

그런 미묘함 때문에 여러가지 형태의 JOIN들이 존재함.

 

LEFT OUTER JOIN에서 NULL이 나온다? 왼쪽 테이블엔 값이 있는데, 그 값에 해당되는 오른쪽 테이블의 행이 없구나

 

 

표 3개를 붙이면? 저 두개 붙였을 때 profile_id가 있는데 옆에 붙이기만 하면 됨, 끝에다 LEFT JOIN 한번 더 하기

앞에서 만든 표에다가 다시 왼쪽방향으로 붙이는 것

테이블이 아무리 많아도 붙일 수 있다.

 

그리고 저기 profile_id, pid이렇게 두개씩 있는거 쳐내려면 출력될 컬럼을 지저하면 된다 맨 아래 문장임

저때 tid는 유일하니까 그냥 써도 되는데 title이라고만 쓰면 에러남, 여러군데에 title이 있기 때문!

DB가 embiguous불평을 함, 앞에 표의 이름을 적어주면 됨 : topic.title

컬럼에 이름 주려면 AS job_title 이렇게 주기 : AS는 별명을 주세요

 

맨 끝에 WHERE aid = 1; 주면

egoing이 작성한 글들만을 가져올 수가 있다.

 

RIGHT OUTER JOIN은 방향만 달라지고 똑같이 동작함. 보통은 LEFT를 많이 씀. RIGHT를 쓸 때가.. 있을까요? LEFT로 환원해서 만들면 되는건데.. 저는 잘 모르겠네요 라고 하심