오라클 DB 에서 트리거로, UPDATE CASCADE 흉내내기

현재 서비스 중인 앱의 기능을 강화하기 위해 다른 회사와 제휴를 맺어 데이터를 정기적으로 받고 있는 것이 있습니다. 

제휴사에서 제공한 DB 정의서에 따라 PK, FK 를 설정해서 개발중이었는데, 테스트를 하던중 중대한 문제가 발생하였습니다. 

PK 로 잡혀 있는 키 값이 제휴사 사정에 의해 변경된다는 것입니다. 이 값이 변경되면, FK 로 연결되어 있는 모든 테이블의 데이터가 변경되어야 하는데, 오라클은 UPDATE CASCADE 기능을 제공하지 않고 있어, 데이터 수정이 불가능 합니다. 

이번만 그렇다면, 잠시 FK 제거하고 데이터 변경후 다시 FK 설정을 하면 되는데, 제휴사에서 종종(혹은 자주) 서비스 개선을 위한 작업의 일환(?)으로 변경될 수 있다고 합니다. 

더군다나, 운영계 시스템에서는 DDL 에 대한 권한이 없기 때문에 프로그램에서 FK 를 제거하거나, 설정할 수가 없습니다. 

그렇다고 FK 를 제거하면, 데이터 정합성의 문제가 존재 합니다. 서비스단 코드에서 제어를 할 수 도 있지만, 개발자가 변경되거나, 시간이 지날 경우 제어코드가 사라지거나, 고도화 과정에서 제어코드를 작성하지 않을 수 도 있습니다. 결국, 서비스단 코드에서 처리하는 것은 미봉책일 뿐입니다. 

DB 단에서 데이터의 관리시점에서 제어를 해주는 것이 가장 좋습니다만, 위에 적은 것 처럼 오라클은 UPDATE CASCADE 기능을 제공하지 않고 있어 약간의 편법(?)을 사용해야 합니다. 

저는 아래의 방법으로 처리 하였습니다. 

일단, 문제가 되는 FK 는 다 제거 합니다. 

그리고, FK 로 연결된 부모 테이블에 UPDATE AFTER TRIGGER 를 생성하고, 자식 테이블에 해당 컬럼의 값을 모두 업데이트 처리 합니다. 

마지막으로 자식 테이블에서 UPDATE BEFORE TRIGGER 를 생성하고, 부모 테이블에 해당 컬럼의 값이 존재하는지 체크 하면 됩니다. 

INSERT, DELETE 역시 위와 동일한 방법으로 설정하면 됩니다. 

이 방법을 사용하면, STORED PROCEDURE 를 사용하는 것 보다 엄청 귀찮습니다. STORED PROCEDURE 를 사용하면, 훨씬 간단하게 처리가 가능합니다. 다만, 비즈니스 로직이 STORED PROCEDURE 에 계속 포함되는 것을 방어 할 수 없게 됩니다. 

결국, DB담당자가 비즈니스 로직을 처리해야 하는 부담을 가지게 됩니다. 

하지만, TRIGGER 를 사용하면, 비즈니스 로직은 서비스단 코드에 그대로 두고, 값에 대한 VALID 처리만 하면 됩니다. 서비스단 개발자의 쿼리나 코드가 변경되는 것이 없으므로, 비즈니스 로직이 넘어 오지도 않습니다. 

단점은 테이블 정의서등에 트리거를 설정한 것을 꼭 작성해 둬야 합니다. 그래야, 다른 자식 테이블이 생성될때, 빼먹지 않고 처리를 할 수 있습니다.