Trigger

훌륭한 트리거의 예시

Trigger는 DB에 대한 수정이 일어나면 자동으로 실행되는 프로시저다. 이를 위해서는 반드시 "언제 트리거가 실행될 지", 그리고 "트리거가 실행되고 나서의 Action을 어떻게 할지" 반드시 명세하여야 한다. 

 

 

 

트리거의 사용 이유와 사용법

Trigger는 SQL의 평범한 제약만으로는 명세하지 못하는 거시기(?)를 실행하는데 사용할 수 있다. 또한 어떤 조건이 충족되면 자동적으로 메커니즘을 실행시키는 데에 사용될 수 있다. 물론 DB 외부의 것을 건드릴 수 없는것은 당연할 것이다. (다만 일부 DBMS의 경우에는 쿼리가 업데이트  되면 이메일을 쏴준다거나 하는 기능을 지원하기는 한다.)

 

create trigger timeslot_check1 after insert on section
referencing new row as nrow
for each row
when (nrow.time_slot_id not in (select time_slot_id from time_slot))
begin
	rollback
    end;

쨋든 문법은 이렇게 생겨먹었고, valid한 update, insert, delete에 대해서 가능하다. 다만 문법은 DBMS 마다 참 다양하게도 구현해 놓았다. 물론 개념은 공통적으로 사용됨으로 SQL Standard로 일단 설명해보도록 하자....

 

처음에는 create trigger name 치고 뒤에 실행되는 경우을 적어 놓는다. 위의 경우에는 section이라는 relation에 대해서 insert가 실행된 뒤를 적어놓았다. (referencing old row as로 해서 이전 데이터 가져오기도 된다.) 그리고 (insert 되서) 새로 들어오는 행들을 nrow라고 이름짓고 when절에서 조건을 정의한다. 그리고 만약 조건에 맞으면 begin ~~ end 사이를 실행하는데, 위의 코드 같은 경우에는 이전 테이블에 없으면 롤백하게 해놨다. 참 쉽죠?

 

 

 

트리거를 사용하지 말아야 할 때

위에서 기술했다 시피 트리거는 참 좋은 친구라고 할 수 있을 것이다. 다만 maerialized view를 관리하는 경우에는 예외가 되시겠다. 물론 트리거로도 되긴 하는데, 많은 DBMS의 경우에는 자동적으로 이를 관리함으로 굳이?

 

더불어 백업 카피를 불러오거나 백업을 만들때 트리거가 의도치 않은 동작을 일으킬 수 있다. 물론 이에 대비해서 몇몇 DBMS 시스템들은 not for replication이라는 단서 조항을 달아놓을 수 있게 한다. 

 

그리고 당연히 (event성 기능이 그렇지만) 트리거가 잘못 동작하면 다른 트리거에도 영향을 미치거나 - 최악의 경우 뺑뻉이가 발생할 수 있다. 그리므로 Trigger는 최대한 신중하게 사용하는 것이 좋으며, 만약 대체 수단이 있다면 굳이..?