1. CASE
등록한 일정을 변경해야 할 경우 ‘일정 변경 요청’을 하는데 이때 일정 변경 전후도 함께 보여줘야 했다. 어느 날 문제가 생겼다고 연락이 왔는데 일정 변경 후의 데이터가 뜨지 않는다는 것이었다.
기존에는 일정 변경 전과 후의 데이터를 각각 임시 테이블에 INSERT 후 보여주는 방식이었다. 원인은 하루에 중복된 일정이 들어갈 시 고유 제약 조건을 위배하는 문제가 생기는 것이었다.
전후 데이터를 보여주기만 하면 되었기 때문에 임시 테이블을 사용하지 않아도 될 것 같아 쿼리 리팩토링을 하기로 결정하였다.
2. How to Use
1) 리팩토링 전
① TR_1, TR_2 데이터 삭제
② TR_1 인서트 : source(원본 자료) target(대상 자료)
③ TR_2 인서트 : source(원본 자료)
④-1 원본 자료의 작업 일자와 인력 ID가 추가되는 자료와 동일한 원본 자료만 TR_2에 업데이트
④-2 업데이트된 대상 자료를 구분하기 위해 flag를 1로 변경
⑤ 추가되지 않은 나머지 일정의 자료를 그대로 TR_2에 추가
→ 스케줄 변경 이력을 추적하면서 인원 배정을 자동으로 조정
2) 리팩토링 후
일정 등록 시 데이터를 임시로 저장하는 테이블에서
① 전 스케줄 ID를 PK으로 잡아 BF로 가정
② 후 스케줄 ID를 PK으로 잡아 AF로 가정
③ BF와 AF를 FULL OUTER JOIN을 걸어 둘 중 하나만 있는 경우도 모두 포함
→ 한 번의 SQL 실행으로 결과를 도출
3. Reviewww
리팩토링한 쿼리는 PK를 이용하여 실행 결과를 도출하는 방식으로 수정했다.
기존에는 왜 임시 테이블을 이용했을까? 만약 데이터를 가공해야 할 일이 생겼을 경우 임시 테이블을 이용하여 가공하는 것이 용이하기 때문에 사용하지 않았을까 싶다.
리팩토링한 쿼리는 조인 조건이 많아지면 성능이 저하될 가능성이 있지만 해당 기능에서는 조회만 하면 되었기 때문에 쿼리를 개선할 수 있었다고 생각한다.
업무를 쳐내면서 느끼는 건 어떤 코드(쿼리)든 배울 점이 있다는 것이다. 이유 없는 코드는 없고, 설령 성능이 떨어지는 코드라고 하더라도 지금 나에게는 다양한 케이스를 접해보고 배우는 게 중요하지 않을까?