직접 작성해본 쿼리 후기 - (1)

최근 업무로 조회 쿼리를 직접 작성해볼 일이 생겼다.

쿼리를 작성하는 과정에서 겪은 내용과 느낀 점을 정리해보려 한다.

 

 

배경

한참 오래된 시스템에 신규 기능을 개발할 일이 생겼다.

 

신규기능이라고는 표현했지만 기능을 만들고,

결국에는 그 기능을 직접 사용해서 통계 자료를 추출해 제공해야 하는 상황이었다.

(프로젝트 사정 상 어쩔 수가 없는 상황.)

 

 

기존 프로그램에 기능을 신규 개발하여 테스트를 진행한 결과 1건당 대략 3~4시간씩 소요됐는데,

총 252건의 작업이 필요했기 때문에 어마어마한 시간 투자가 예상됐다.

 

데이터 양 자체가 많은 편은 아니었지만,

해당 프로그램에 들어가는 엔진에서 자체적으로 매핑해주는 데이터들이 통계자료의 핵심이었고

엔진에서 매핑해주는 값들을 추출해내기 위해 값 하나하나마다 쿼리를 반복해서 날려야했기 때문에 시간이 오래 걸렸다.

 

프로그램적으로 더 좋은 방안이 있었을지도 모르지만, 내 파트가 아니었기도 하고 엔진 자체가 워낙 구형이라 관련 정보를 찾기도 힘들었다.

 

 

개발 외적인 부분에 시간을 너무 많이 소요하는 것 같아 조금 더 빠르게 해결하는 방법을 생각해보다가

 

"엔진이 매핑해주는거면 테이블 어딘가에는 매핑할 수 있는 정보가 저장되어 있지 않을까?"

"만약 그렇다면 매핑되는 테이블을 직접 찾으면 쿼리 한번에 조인해서 조회할 수 있지 않을까?"

하는 결론에 이르렀다.

 

 

선임께 조심스럽게 보고드렸고, 전권(?)을 위임받아 해당 문제를 직접 해결해보게 되었다.

 

 

과정

앞서 말한 252개 작업에 필요한 정보들은 각각 독립적인 테이블스페이스로 구성되어 있었다.

각 테이블스페이스를 들여다보니 기존 정보들이 담긴 테이블 외에 F848, F849, F850 같은 시퀀싱된 테이블이 보였고,

테이블스페이스마다 숫자는 다 다르지만 우리가 필요했던 정보 중 일부인 것은 확실했다.(자세한 설명은 생략)

 

하지만 저 F848같은 테이블이 한 테이블스페이스 당 20개 가량 있었는데, 이걸 어떻게 매칭시켜서 필요한 정보를 찾아야 하는지에 대한 문제가 남아있었다.

 

다행히 엔진 내부적으로 사용하는 META 정보들 또한 별도의 테이블스페이스로 관리되고 있었고, 해당 테이블스페이스의 접근이 열려있어서, 안의 테이블을 전부 까뒤집어서 매핑 관련 정보가 담긴 테이블을 찾아냈다.

 

이후에 본격적으로 쿼리를 작성해 보면서, 레거시에 대한 이해도가 높아졌다.(?)

 

 

쿼리에 대한 내용은 다음 글로 이어서 써보도록 하겠습니다.