조직도 쿼리 개선

 

[개선했던 이유]

데스크탑 미니모드에서만 사용하던 조직도를 웹에서도 오픈할 예정이어서

기존에 조직도 탐색 시 아래의 거슬렸던 문제들을 해결하고자 개선을 진행했었다.

 

1. 전문을 사용자 depth 만큼 여러 번 호출하는 점 

조직도가 펼쳐진 상태에서는 나의 소속 상위부서 뿐만 아니라 

소속상위부서 하위의 같은 depth 부서들도 함께 조회해야 하기 때문에 재조회가 필요하다.

이 과정을 이전의 방식은 (최상위 -> 내 소속 부서)까지 한 depth 한 depth씩

js에서 반복분으로 찾아들어가 쿼리를 호출하도록 개발되어있었다.

 

2. 속도가 오래 걸리는 점 

그러다 보니 안 그래도 슬로 쿼리로 이뤄져 있던 api인 데다가

depth가 깊은 경우에는 상위부서 값만 다르게 넘기는 동일 api의 수많은 호출이 일어나고 있었다.

사용자의 입장에서 페이지가 느리게 로딩된다고 느껴질 수밖에 없는 구조였고

쿼리 자체의 cost도 높았다.

 

3. 리컬시브 무한 방지가 안되어있는 점 

기존에 사용하던 RECURSIVE 쿼리의 경우 반복을 멈추는 조건이 들어가지 않아, 

만약 사용자의 상위부서와 하위부서가 같을 때 무한으로 반복될 수 있는 위험이 있었다.

한마디로 tree.상위부서 != '내 소속부서'  조건이 누락됨.

 

 

 

[개선 결과]

-  기존 실행 시  총 cost : 3354 + a (소속된 depth 만큼 하위부서를 조회하는 전문 재실행)

 

-  개선 후 실행시 총 cost : 140

 

개선 후에는 리컬시브로 얻은 부서들과 동일한 depth에 있는 부서들을

바로 한 번에 들고 와서 처리할 수 있게 쿼리를 짰다.

조직도 쿼리는 recursive + join + sub쿼리 조회가 섞여있기 때문에 index를 최대한 잘 활용해야 했다.

 

(이때 몰랐던 건 한 번에 들고오는게 문제가 아니라, 한번에 담아서 들고 온 애들을

조건에 맞춰서 하나하나 js에서 깊이에 맞게 뿌려주는 게 진짜 hell이었다)

 

[개선 후 1달 뒤 오늘 발견한 오류]

나는 '최상위 부서 === 무조건 해당 기업'이라고 생각하고 개발을 진행했는데,

일부 회사에서는 최상위 부서 자체가 여러 개일 수 있었다.

(정확히는 최상위 부서와 동일선상의 부서가 여러 개)

 

확실히 조직도에서는 온갖 경우의 수를 따지고 테스트를 다 해봐도

고려해야 하는 케이스가 내가 생각하는 것보다 훨씬 다양한 것 같다.

어쨌든 오늘 다시 쿼리 수정해서 함께 가져와서 뿌려주도록 전문 + js 변경 완료했다.