개발자인가 설계자인가

지난번 

[SQL]#1. SQL 작성순서?

에서는 SQL을 작성하는 순서를 얘기했었다 

#1 의 마지막에 

SQL을 작성하기 어려운 두가지 문제를 말했었다.

물론 두가지 보다 더 많은 이유가 있지만 가장 원인이 되는 두가지를 살펴 보자 

(이 두가지 이외에 다른 문제들도 다뤄 본다.)

 ** 단순 조인은 할 수 있다는 전제로 설명 **

1. 원하는 데이터가 TABLE 로 없다...

이게 무슨 말인가 하면 

우린 기본적으로 DML을 안다. 그러니 우리가 원하는 Column이 특정테이블에 있다면 

SQL을 작성하는데 아무 문제가 없다.

근데 현실은 그렇지 않다. 예를 들어 

T1 테이블에 매출 데이터가 있다고 가정하자. 당연히 판매일자 , 판매처, 품목, 수량, 단가, 금액등이 있을것이다 

(조회 기준 : 판매일자 >= 20191101 & 판매일자 <=20191130) 

실제로 조회는 이렇게 단순히 하는게 아니라 

[[11월 판매 데이터와 각 판매처 별로 11월 이전 가장 최근 데이터를 구하고 또

평균 구매간격과, 총 구매금액을 같이 조회 ]] 하고 싶다면..

단순히 select * from T1 으로는 안된다.

지금 여기서 말하고 싶은건 단순히 어떤 기술적인 요소를 말하고 싶은게 아니다. 

본인이 말하고 싶은건 @1 이럴때 우린 어떤 사고방식을 가져야 하는가? or 어떻게 접근해야(생각해야) 하는가?? 이다.

이 @1 부분이  sql 작성시에 초급 개발자들을 막막하게 하는 것이다.

본인은 이렇게 권한다.

1. 아래와 원하는 데이터가 있는 그렇게 생긴 테이블이 있다고 가정을 하라 ( Excel 등에 적어 두는걸 권장) 

   가상의 테이블 이름도 지어주자. 여기선 PT1.

2. T1과 PT1의 조인 관계를 생각해 보자

PT1은 판매처별로 데이터가 있다 그러니 T1과의 조인은 판매처만으로 조인이 될것이다. 

3. 그럼 우린 [[ ]]  를 작성하는게 아니라 PT1을 작성하는 셈이 되는것이다. 

PT1만 작성할수 있다면 결국 T1과 조인만 하면 [[ ]]  내용이 완성 되는 것이니까.

PT1의 내용이 이렇게 단순하지 않다면 ?? 다시 PT1-1 , PT1-2 , PT2 등을 분리하여 생각 하면 그만이다.

우리는 이 PT1.. 등을 생각해 내는걸 "집합적인 사고방식" 이라고 한다. 

이게 된다면 SQL 작성의 80%는 끝난 것이다. 

4. 속도는요? 

일단은 속도를 신경쓸 겨를이 없지 않은가? 걷지도 못하는데 날려고 하는 꼴이다.

2. JOIN의 개념을 모른다.

JOIN을 아는가, 모르는가 의 얘기를 하려는 것이 아니다. 

JOIN 할때 어떤 부분을 생각하고 고민해야 하는지를 말하려고 한다.

1. JOIN은 곱하기다. 

T1 에 2개의 ROW가 있고 T2에 4개의 ROW가 있다면 아래와 같이 아무 조건없이 

SELECT COUNT(*) FROM T1, T2 

이렇게 쿼리를 한다면 결과는 8 이다 .  당연하다 JOIN은 곱하기 이고 

조건이 없고 각 테이블에 2개의 로우가 있으니 2x4=8

이말은 어떤 COLUMN으로 서로 조인했을때도 동일하다. 

이 곱하기 되는 부분을 고민 해야 한다. 

2. 누가 메인이야? 

T1, 과 T2 에서 어느 테이블이 주 테이블인가? (어느 테이블이 더 중요한가) 

예를 들어 

T2는 무조건 나와야 한다면 OUTER 는 T1이 되는 것이다 .

SELECT T2.KEY, T2.CODE, T2.NAME , T1.NAME

FROM  T2 LEFT JOIN T1 ON T2.KEY = T1.KEY 

위 SQL을 해석하면  "행 기준으로!! T2는 무조건 나오고 T1 은 있으면 나오고 없으면 말고" 라는 뜻이다. 

그러니 T2.KEY 에 있는 값이 T1.KEY 에 없다고 하더라도 무조건 나오게 된다. 

사실 Join은 이보다 더 어려운 개념이지만 위의 두가지 개념을 확실히 해야 다음으로 넘어갈 수 있다.

3. 다른건 없나요?

다른 요인도 많지만 위의 1,2 항목이 가장 기본이라 할 수 있겠다 

참고로 몇가지 더 말해보면 

1. 함수 및 문법 숙지 : 각 DBMS에서 제공하는 함수와 그 사용처 문법을 숙지 하는것

2. 많이 작성해 볼것 : 말할것도 없다.

3. 자신만의 SQL 사전을 관리 할 것 : 인테넷에 많이 있지만 본인만의 설명으로 본인이 이해할수 있는 sql 사전을 만들면 좋다. 

 4. 동일한 결과를 분석함수를 쓸때와 안쓸때를 구분해 볼것.  : 분석함수는 각 DBMS에서 제공해주는 매우 유용한 함수이지만 분석함수를 쓰지 않고 동일한 결과를 만들어 내는 연습을 하면 SQL 작성에 많은 도움이 된다.

5. 옵티마이져가 되어 볼것 : 우리가 SQL을 작성하고 실행하면 각 DBMS의 옵티마이져가 이를 분석/해석하고 처리하게 된다. 그 역할을 상상하고 되어 보는것도 매우 많은 도움이 된다.

6. 테스트 테이블을 가질것 : 자신만의 테스트 테이블을 가지는게 좋다 부분 부분의 sql을 작성해볼 수 있는 테스트 테이블을 통해 실제 결과를 눈으로 확인하면서 SQL을 작성해 본다 

7. 주석의 관리 : SQL도 주석을 달 수 있다. 다음 운영자를 위해서라도 주석을 꼼꼼히 다는 습관을 지녀야 한다.

8. 지난 SQL 검토 : 예전에 작성한 SQL을 검토해 본다 (당시 작성할때 고생했던 SQL들) ... 뭐 해보면 알것이다.

이상 SQL의 작성 순서와 작성시 왜 어려웠는지 알아봤다.

근데...결국은 스스로 해보고 답을 찾아야 한다. 

위에 작성한 내용 역시 그렇게 찾은 결론이다. 

정답이 아닐수 있겠고 정말 SQL을 잘 하시는 선수들이 보면 뭐라 할지 모르겠다 ㅎㅎ 

그럼 이만~