프로시저, 함수, 트리거 비교

프로시저, 함수와 트리거의 호출, 반환값, COMMIT과 오류 차이 및 이기종 이행 전 비교 항목

PL/SQL프로시저함수트리거EXECRETURNOUT 매개변수ORA-04092이기종 이행

#핵심 요약

구분	프로시저	함수	트리거
실행 방법	`EXEC 이름(값)`으로 사람이 호출	SQL, PL/SQL 안에서 식처럼 호출	DML이 일어나면 자동 실행
돌려주는 값	없음(필요하면 OUT 매개변수)	`RETURN`으로 반드시 1개	없음(`:NEW` 값을 바꿀 수는 있음)
SELECT 안에서 사용	불가	가능	불가
안에서 COMMIT	가능(넣을지는 설계)	SELECT 안에서 부르는 함수는 불가	불가(`ORA-04092`)
대표 오류	`PLS-00306`(인자 개수, 타입)	`PLS-00221`, `ORA-06503`	사용자 정의 `ORA-20xxx`
조회할 데이터 사전	`USER_OBJECTS`, `USER_SOURCE`, `USER_ARGUMENTS`	`USER_SOURCE`, `USER_DEPENDENCIES`	`USER_TRIGGERS`, `USER_SOURCE`

#개념과 동작 원리

실습에서는 이 비교를 이기종 데이터베이스 이행 수업 안에서 다뤘음
PostgreSQL과 MySQL로 이행할 때 테이블, 데이터, 제약조건, 시퀀스는 SQL만으로 옮겨졌지만, 프로시저(add_order, raise_sal, send_report), 함수(get_grade), 트리거(trg_orders_ai)는 다른 DB 문법으로 다시 써야 했음
그래서 먼저 Oracle에서 같은 종류의 객체를 직접 만들어 구조와 동작을 확인하는 것이 목적이었음

이행 전 비교할 차이:

프로시저 안에 COMMIT이 있는지 없는지는 이행 후 트랜잭션 동작이 달라지는 중요한 차임
실습의 p_raise_sal은 COMMIT이 없고 소스의 add_order는 있음(IN과 OUT 매개변수)

함수는 행마다 한 번씩 호출되므로, 테이블을 조회하는 함수를 대량 데이터 SQL에서 쓰면 이행 후 성능 문제의 원인이 됨(함수와 RETURN)

트리거는 어느 경로로 DML이 들어와도 실행되므로, 이행에서 빠뜨리면 업무 규칙이 조용히 사라짐(BEFORE와 AFTER 트리거)

이기종 이행 절차 자체는 데이터 이행과 적재 분야에서 다룸

#필수 명령어 또는 SQL

SQL*Plus (객체 소유 계정)조회만 함

SELECT object_type, object_name, status
  FROM user_objects
 WHERE object_type IN ('PROCEDURE', 'FUNCTION', 'TRIGGER')
 ORDER BY object_type, object_name;

결과 해석: 세 종류 객체의 이름과 상태(VALID/INVALID)를 한 번에 봄
상태와 소스 조회는 객체 상태와 소스 조회에 있음