Stored Procedure

• 저장 프로시저란 SQL 서버에서 제공하는 프로그래밍 기능으로 쿼리문의 집합이 특정한 동작을 일괄 처리하기 위한 용도로 사용된다.

특징

• SQL Sever 성능을 향상할 수 있다.
• 동일한 저장 프로시저가 자주 사용될 경우 일반적인 쿼리를 반복하는 것보다 성능이 크게 향상될 수 있다.
• 모듈식으로 저장 후 언제든 실행이 가능하다
• 보안 강화와 네트워크 전송량을 감소시킬 수 있다.

Example

CREATE OR REPLACE procedure name 
   IN argument 
   OUT argument 
   IN OUT argument 
 
IS 
 
   [변수의 선언]
 
BEGIN  --> 필수 
 
   [PL/SQL Block] 
   -- SQL문장, PL/SQL제어 문장 
 
   [EXCEPTION]  --> 선택
  -- error가 발생할 때 수행하는 문장
 
END;  --> 필수 
    

-- 프로시저의 이름은 update_sal이다 
-- update_sal 프로시저는 사번을 입력받아 급여를 인상 한다. 
-- 프로시저를 끝마칠 때에는 항상 "/"를 지정 한다.
create or replace procedure update_sal
    /* IN Parameter */
    (empno_val IN NUMBER)
IS
BEGIN
    update employees
    set salary = salary+9
    where employee_id = empno_val;
END update_sal;
/

PROCEDURE vs FUNCTION

• 둘의 가장 큰 차이는 리턴값의 유무
• 사실 원래 procedure로 제작을 하였으나 postgresql10에서 지원을 안해 function으로 수정하고 return void를 활용하였다.

Django에서 접근

from django.db import connection
c = connection.cursor()

try:
	c.callproc( 함수 or 프로시저, (파라미터))
except:
	예외 처리
finally:
	c.close()

PROCEDURE VS ORM

1. ORM 장점
   • 로직의 파편화가 적어지며 재사용이 용이(유지보수 고려)
   • 저장 프로시저에 비해 테스트 구성이 쉽다
   • Git처럼 버전관리 프로그램에서 추적이 쉽다(변화를 쉽게 파악할 수 있다.)
   • 기존 CI/CD 파이프라인을 통해 배포 관리가 쉽다.
2. Procedure 장점
   • 프로시저명을 받기 때문에 상대적으로 네트워크 트래픽이 적다.
   • DB에서 로직을 직접 실행시키기 때문에 속도가 매우 빠르다.
   • 특정 DB에서 제공하는 세밀한 기능들을 직접 사용
   • 컴파일 없이 DB에 바로 업데이트
   • 디버깅이 쉽다.

• 최근 작업을 통해 속도면에선 Procedure가 훨씬 더 빠르다고 느꼈다. (물론 Django 최적화가 부족해서 확실하게는 말 못하지만) 하지만 계속해서 자료를 찾아보니 단순히 속도를 생각하는 것이 아니라 앞으로의 개발 방법을 고려해야함
  가령 프로시저의 경우 빠르게 개발하고 빠른 반응을 볼 수 있지만 현재 99퍼센트 이상을 ORM으로 구현한 상태에서 갑자기 프로시저를 사용함에 따라 향후 유지보수에 고려해야할 것이 늘어났고 쉽게 비용이 증가했다고도 볼 수 있다.
  물론 현재 직면한 대량 업데이트는 이 방법이 효율적이겠지만 그렇다고 모든 것을 프로지서로 작업하기엔 애매함이 남는다.