Search

BQ-01. 같지 않은 기준코드 찾기

고객들에게 여행 상품을 예약하는 시스템을 구축 중이다. 개발 데이터베이스와 운영 데이터베이스가 있으며, 두 데이터베이스는 동일한 스키마(테이블 구조 또는 데이터베이스 구조)를 가지고 있다.
데이터베이스에는 다음과 같은 구조의 기준코드를 관리하는 테이블이 존재한다.
기준코드
cm_base_cd
기준코드구분(PK)
base_cd_dv(PK)
기준코드(PK)
base_cd(PK)
기준코드명
base_cd_nm
기준코드는 시스템을 운영하는데 매우 중요한 핵심 테이블이다. 기준코드를 함부로 변경하거나 삭제하면 기준코드를 사용하는 프로세스에서 치명적인 오류가 발생할 수 있다. 또한 개발전에 기준코드를 잘 정비해야만 개발하는 과정에 불필요한 재작업이 생기지 않는다. 이처럼 중요한 기준코드 데이터가 개발과 운영간에 상이한 문제가 발생했다. 이로 인해 개발 과정 뿐만 아니라 의사소통에도 문제가 생기고 있다. 개발과 운영의 기준코드 데이터를 살펴보면 다음과 같다.
개발 데이터베이스의 기준코드 데이터
base_cd_dv
base_cd
base_cd_nm
onwy_rntr_dv
01
편도
onwy_rntr_dv
02
왕복
pay_tp
01
카드
pay_tp
02
계좌이체
trv_mod_tp
01
비행기
trv_mod_tp
02
기차
trv_mod_tp
03
크루즈
trv_mod_tp
04
버스
if_type
01
SEND
if_type
02
RECEIVE
운영 데이터베이스의 기준코드 데이터
base_cd_dv
base_cd
base_cd_nm
onwy_rntr_dv
01
왕복
onwy_rntr_dv
02
편도
pay_tp
01
카드
pay_tp
02
계좌이체
trv_mod_tp
01
비행기
trv_mod_tp
02
크루즈
trv_mod_tp
03
기차
mbr_gd
01
VVIP
mbr_gd
02
VIP
mbr_gd
03
GOLD
개발과 운영의 두 데이터 집합을 살펴보면, base_cd_dv(기준코드구분) 별로 pay_tp 외에는 모두 다르다. 정리해보면 다음과 같은 차이가 있다.
onwy_rntr_dv의 경우, 개발에서는 01이 편도이지만, 운영은 01이 왕복으로 되어 있다.
trv_mod_tp의 경우, 개발에는 버스가 있지만 운영에는 버스가 없다.
개발에는 if_type이 있지만 운영에는 없다.
운영에는 mbr_gd가 있지만 개발에는 없다.
기준코드를 맞추기 위해서는 담당자들에게 어느 기준코드구분이 다른지를 담당자들에게 추출해 주어야 한다.
아래는 SQL 작성 연습을 위해, 위에서 보여준 기준코드 테이블과 데이터를 생성하는 스크립트입니다. 편의를 위해, 개발 데이터베이스의 기준코드 테이블은 cm_base_cd_in_dev란 이름으로 생성하고, 운영 데이터베이스의 기준코드 테이블은 cm_basd_cd_in_prod란 이름으로 생성한다. (아래 스크립트는 PostgreSQL 기반으로 작성되어 있다. MySQL에서도 실행가능하며, ORACLE의 경우 버젼에 따라 INSERT 구분만 약간 변경해서 실행하면 된다.)
-- 개발DB의 기준코드 테이블 CREATE TABLE cm_base_cd_in_dev ( base_cd_dv varchar(40) NOT NULL ,base_cd varchar(40) NOT NULL ,base_cd_nm varchar(100) ,PRIMARY KEY(base_cd_dv, base_cd) ); -- 운영DB의 기준코드 테이블 CREATE TABLE cm_base_cd_in_prod ( base_cd_dv varchar(40) NOT NULL ,base_cd varchar(40) NOT NULL ,base_cd_nm varchar(100) ,PRIMARY KEY(base_cd_dv, base_cd) ); -- 개발DB의 기준코드 데이터 INSERT INSERT INTO cm_base_cd_in_dev (base_cd_dv, base_cd, base_cd_nm) VALUES ('onwy_rntr_dv','01','편도') , ('onwy_rntr_dv','02','왕복') , ('pay_tp','01','카드') , ('pay_tp','02','계좌이체') , ('trv_mod_tp','01','비행기') , ('trv_mod_tp','02','기차') , ('trv_mod_tp','03','크루즈') , ('trv_mod_tp','04','버스') , ('if_type','01','SEND') , ('if_type','02','RECEIVE') ; -- 운영DB의 기준코드 데이터 INSERT INSERT INTO cm_base_cd_in_prod (base_cd_dv, base_cd, base_cd_nm) VALUES ('onwy_rntr_dv','01','왕복') , ('onwy_rntr_dv','02','편도') , ('pay_tp','01','카드') , ('pay_tp','02','계좌이체') , ('trv_mod_tp','01','비행기') , ('trv_mod_tp','02','크루즈') , ('trv_mod_tp','03','기차') , ('mbr_gd','01','VVIP') , ('mbr_gd','02','VIP') , ('mbr_gd','03','GOLD') ;
SQL
복사
이제, 담당자들에게 어떤 기준코드구분이 개발과 운영이 다르다는 것을 어떻게 보여줄 수 있는지 고민해보기 바란다. 다양한 방법으로 표현할 수 있으며 다양한 SQL로 이를 구현할 수 있을 것이다.
필자는 아래와 같이 결과를 추출할 것이다. 기준코드구분을 구성하는 코드들을 list화해서 비교 처리하는 것이다.
위와 같은 비교 방식 추출은 비교적 SQL이 간단(?)하다는 장점이 있다. 반면에, 기준코드구분에 속하는 코드 데이터들을 콤마(,)로 구분해 하나의 필드로 보여주면서 보여줄 수 있는 양의 한계와 성능의 이슈가 있을 수 있다는 단점이 존재한다. 다행히도 기준코드구분 별로 100개의 기준코드를 넘어가는 경우는 업무적으로 잘 없기 때문에 충분히 위와 같은 리포트를 만들 수 있다.
꼭 위와 같이 결과를 추출하지 않아도 된다. 각자 생각하는 다양한 방법을 사용해 개발과 운영의 기준코드가 다른 데이터를 추출해보기 바란다.
위와 같은 결과를 추출한 SQL은 다음과 같으니 참고하기 바란다.
참고 답안
이상입니다.