트리거와의 첫 만남

트리거(혹은 trigger)는 데이터베이스에서 특정 이벤트에 반응하는 일종의 "callback"이야. 다시 말해서, 트리거는 INSERT, UPDATE 또는 DELETE 같은 작업이 테이블에서 실행될 때 자동으로 반응하는 거지.

예를 들어, 네가 똑똑한 어시스턴트를 두고 있다고 생각해봐. 새로운 학생 정보를 추가할 때마다, 어시스턴트가 자동으로 마지막 수정 날짜 필드를 업데이트해주는 거야. 데이터베이스의 트리거도 똑같이 동작해. 이벤트를 "듣고 있다가" 미리 짜둔 반응을 실행하는 거지.

트리거는 두 가지를 조합해:

1. 이벤트: 테이블에서 뭔가 일어남 (예: 레코드 추가).
2. 트리거 함수: 이벤트가 발생하면 실행되는 코드.

트리거 사용 예시

트리거가 유용할 수 있는 상황 몇 가지를 같이 살펴보자.

1. 데이터 자동 업데이트

학생 정보를 저장하는 테이블에 last_modified 필드가 있고, 이 필드는 레코드가 바뀔 때마다 자동으로 업데이트되길 원한다고 해보자. 매번 직접 이 필드를 수정하는 대신, 트리거를 만들어서 자동으로 처리할 수 있어.

2. 변경사항 로깅

누가 언제 테이블의 데이터를 바꿨는지 추적하고 싶을 때가 있지. 트리거는 데이터가 바뀔 때마다 자동으로 audit(로그) 테이블에 기록을 남길 수 있어.

3. 데이터 검증

테이블에 들어오는 데이터가 어떤 규칙을 따라야 할 때(예: 학생 나이가 18살 이상이어야 함), 트리거가 삽입 전에 데이터를 체크할 수 있어.

4. 자동 계산

orders 테이블에 주문을 저장한다고 해보자. 주문이 추가될 때마다 고객의 총 구매 금액을 업데이트해야 한다면, 트리거가 이걸 자동으로 해줄 수 있어.

언제 트리거를 써야 할까?

이제 트리거가 뭘 할 수 있는지 알았으니, 진짜로 언제 쓰는 게 좋은지 얘기해보자.

로깅과 감사: 트리거는 중요한 테이블의 변경사항을 추적하는 audit 기록을 만들 때 딱이야.

데이터 무결성 유지: 예를 들어, 데이터베이스에서 과목을 삭제하면, 트리거가 그 과목에 연결된 학생들도 자동으로 삭제해서 "떠도는" 데이터를 막을 수 있어.

반복 작업 자동화: 계산된 값 업데이트, 집계 데이터 갱신 등 반복적인 작업을 자동으로 처리할 수 있어.

비즈니스 로직을 DB에 구현: 모든 로직을 앱 코드에만 두는 대신, 일부는 데이터베이스 레벨에서 처리할 수 있어.

트리거의 장점

이미 눈치챘겠지만, 트리거는 꽤 강력한 도구야. 이런 점이 좋아:

자동화: 사람이 직접 손댈 필요가 거의 없어. 예를 들어, 누가 데이터를 바꿨는지 추적하는 게 자동으로 이뤄져.

코드 중복 감소: 개발자가 각 앱마다 업데이트나 검증 로직을 따로 짤 필요 없이, DB에 한 번만 넣으면 돼.

데이터 무결성 보장: 트리거는 데이터가 항상 올바르게 유지되도록 추가적인 보호막 역할을 해줄 수 있어.

트리거의 단점

물론, 모든 도구가 그렇듯 트리거도 단점이 있어. 어두운 면도 보자:

• 디버깅 어려움: 트리거는 "백그라운드"에서 동작해. 기대한 대로 안 되면, 어디가 문제인지 찾기 힘들 수 있어.

• 성능 문제 가능성: 트리거가 너무 복잡하거나 자주 실행되면, SQL 쿼리 속도가 느려질 수 있어.

• 숨겨진 로직: 비즈니스 로직이 트리거에 "묻혀" 있으면, 개발자가 실제로 DB에서 무슨 일이 일어나는지 파악하기 어려워져.

실제 사용 시나리오

예시 1: 변경사항 로깅

예를 들어, students 테이블에 학생 정보를 저장한다고 해보자. 레코드가 바뀔 때마다 변경사항을 추적하고 싶어. 이럴 때 트리거가 audit_log 테이블에 학생 데이터가 바뀔 때마다 기록을 추가해줄 수 있어.

예시 2: 자동 업데이트

students 테이블에 last_modified 컬럼이 있다고 해보자. 학생 데이터가 바뀔 때마다 이 값이 자동으로 갱신되길 원한다면, 업데이트 후에 실행되는 트리거로 처리할 수 있어.