HAVING

앞서 궁금했던 부서원의 급여총합이 9000을 넘는 부서는 HAVING을 쓰니 20번과 30번 부서로 판명났다.

 

조건을 두개씩 걸 수도 있다. 30번 부서는 부서원 급여총합이 9000을 넘겼지만 부서번호가 10, 20번에 해당하지 않아서 최종 결과에서 탈락했다. 30번부서는 저희와 함께갈 수 없습니다. 

 

 

근데 이 문장, 이렇게도 쓸 수 있지 않을까?

 

실행 결과는 같다. 그런데 아랫쪽이 성능이 더 좋고, 잘 쓰여진 문장이다. 

• 윗 문장은 : 일단 그룹을 부서별로 다 지어주시는데요, 10번이랑 20번 부서 빼고는 다 날려주세요 (^^)
• 아랫 문장은 : 10번이랑 20번 부서만 남겨주시고요, 부서별로 그룹지어주세요 

윗 문장은 일단 서버가 부서별로 그룹짓는 고생을 다 하고 나서 날리는거라 부하를 많이 받는다. 필요치 않은 일반 조건이 있다면 where에서 먼저 날려주는 것이 성능 좋은 문장을 만드는 방법이다. 

 

 

또, HAVING에 조건을 이런식으로 거는건 안된다. 이미 그룹을 지어놨으면 이미 그룹으로 꽁꽁뭉쳤기 때문에 갑자기 개개인별로 다를 수밖에 없는 1981년에 입사한 걸 조건으로 내걸면 곤란하다. 

 

추가로, where 이 후보행 하나씩을 두고 판단하는 것처럼

having 은 그룹 하나씩을 두고 판단하기 때문에 그룹별 비교는 불가능하다.

그룹으로 이미 묶인 후에 그 그룹값이 어떠하다는 T/F를 판단할 수는 있다.

 

뭔가 1981년 어쩌구..를 꼭 보고 싶다면 이런식으로는 가능하다. 일단 WHERE절에서 1981년 입사자만 남기고 행을 다 날린다. 그리고 81 입사동기들만 남은 상태에서 부서별로 그룹을 짓고, 그 안에서 합이 9000 이상인 경우만 남기겠다는 식으로.

 

참고로 GROUP BY로 그룹을 지어놨으면 SELECT에서 함수는 보통 두번정도만 중첩이 가능하다. 무슨소리냐면, 

일단 부서별로 그룹을 묶어놓고 걔네들의 급여합계를 SELECT에서 물어봤으면 이미 컬럼이 하나밖에 없다.

얘를 MAX, MIN, AVG, 뭘 해도 일단 하나의 값만 남게되어서 그 이상으로는 더 중첩하는 의미가 없다.

아 근데 이 값이 만약에 소숫점이다 그럼 TRUNC 요런거 한번정도는 더 쓸 수 있을 거다.