DATOR


개발자는 SQL로 소통한다!! . . . (주)엔코아 김철기 수석 컨설턴트 커버 스토리


coverstory.jpg 
 
프로젝트를 수행하면서 다른 사람이 만들어 놓은 SQL을 많이 접하게 되는데 가독성이 떨어지는 SQL을 만나게 되면 파악하는 데에만 적지 않은 시간이 소요되고 작성자를 찾아서 물어보더라도 본인도 파악하지 못하는 경우도 쉽게 볼 수 있다.
애초에 만들 때부터 결과를 내는데 급급해 하지 말고 가독성을 고려했다면 이런 시간을 아낄 수 있을텐데 하는 아쉬움이 남게 된다

가독성을 위해서 SQL을 만들 때 염두에 두었으면 하는 사항을 몇가지 얘기하고자 한다.

우선 SQL을 식별할 수 있는 SQLID를 만들어서 주석으로 포함시키자.
문제가 되는 SQL을 발견해놓고도 어디서 발생시킨 SQL인지 찾기 위해서 소스를 뒤져봐야 하는 경우가 많다. 이 때 SQL표준에 따른 SQLID가 포함되어 있다면 쉽게 찾을 수 있다.
요즘에는 웹프로그램에서 SQL을 사용할 때 SQL을 리소스로 관리하면서 조건 유무에 따라 조건절을 Dynamic하게 구성해서 실행시키게 되는데 이 때 조건을 바꿔 실행할 때마다 SGA에 각각 다른 SQL로 올라오게 된다. 
이럴 때에도 SQLID가 있다면 쉽게 같은 SQL을 구분해 낼 수 있다.

두 번째로 조인 테이블의 받아 먹는 조건을 왼쪽으로 배치하여 Access path를 쉽게 파악하도록 하자.
드라이빙 순서대로 나열하는 건 통계 정보에 따라 Optimizer에 순서를 일임하는 요즘에는 의미가 없다 하더라도 SQL의 업무 규칙으로서 Access path를 파악하고자 할 경우가 많다. 
이럴 때 왼쪽에 순서대로 나열된 Access path를 만나게 되면 아무리 긴 SQL이더라도 조인 조건을 쉽게 파악할 수 있다.

 그림1.gif
 
 
위와 같이 구성된 간단한 SQL도 S, T, M 테이블 각각의 Access path를 한 눈에 파악하기는 어려울 것이다.
조건절의 나열 순서만 조정한다면 한 눈에 파악할 수 있다.

한 가지 더 보자면 SELECT 절의 comma위치도 WHERE 절의 AND 위치와 같이 왼쪽에 배치하면 테스트하면서 주석 처리하기에 용이하다.
(현재 IDO manger의 SQL formatting 기능이 이 부분이 아쉽다…)

앞서 말한 내용으로 SQL을 리팩토링하면 아래와 같다.

그림2.gif
 
SQL을 만드는 사람은 결과를 만들어내는 데에만 그치지 말고 훗날 SQL을 다시 찾아볼 사람을 위해(본인이 될 수도 있음) 가독성 있게 만드는 데 노력을 기울여야 할 것이다. 

Tag :

Leave Comments