스토어드 프로시저란
저장 프로시저 또는 스토어드 프로시저(stored procedure)는 일련의 쿼리를 마치 하나의 함수처럼 실행하기 위한 쿼리의 집합이다. 데이터베이스에 대한 일련의 작업을 정리한 절차를 관계형 데이터베이스 관리 시스템에 저장한(지속성) 것으로, 영구저장모듈(Persistent Storage Module)이라고도 불린다.
데이터베이스 언어 표준 SQL에서는 SQL / PSM 기준으로 책정되어 있다. 벤더(제조사) 각사 모두 정적, 동적 SQL에 커서 처리 및 제어 구문, 예외 처리 등을 포함한 사양의 확장 언어로 절차를 설명할 수 있는 DBMS를 제공하는 경우가 많다. 또한 C 언어로 작성된 컴파일한 외부 모듈(공유 라이브러리) 및 Java 클래스 라이브러리에서 함수나 클래스 메소드를 호출하는 것으로 실현하는 ‘외부 프로시저’ 기능을 구현하는 것도 있다. 저장프로시저를 사용하여 다음과 같은 장점이 있다.
하나의 요청으로 여러 SQL문을 실행할 수 있다. (네트워크에 대한 부하를 줄일 수 있다.)
미리 구문 분석 및 내부 중간 코드로 변환을 끝내야 하므로 처리 시간이 줄어든다.
데이터베이스 트리거와 결합하여 복잡한 규칙에 의한 데이터의 참조무결성 유지가 가능하게 된다. 간단히 말하면 응용 프로그램 측 로직을 가지지 않고도 데이터베이스의 데이터 앞뒤가 맞게 될 수 있다.
JAVA 등의 호스트 언어와 SQL 문장이 확실하게 분리된 소스 코드의 전망이 좋아지는 것, 또한 웹사이트 등 운용 중에도 저장프로시저의 교체에 의한 수정이 가능하기 때문에 보수성이 뛰어나다.
저장프로시저를 많이 사용하면 다음과 같은 단점이 있다.
데이터베이스 제품에 대해 설명하는 구문 규칙이 SQL / PSM 표준과의 호환성이 낮기 때문에 코드 자산으로의 재사용성이 나쁘다.
비즈니스 로직의 일부로 사용하는 경우 업무의 사양 변경 시 외부 응용 프로그램과 함께 저장프로시저의 정의를 변경할 필요가 있다. 이때 불필요한 수고와 변경 실수에 의한 장애를 발생시킬 가능성이 있다
참조:위키피디아
장점
-
복잡한 데이터 로직
데이터베이스 내에서 복잡한 계산이나 로직이 필요한 경우에는 스토어드 프로시저를 활용. 데이터베이스 내에서 로직을 처리하면 네트워크 오버헤드가 감소하고, 성능 향상을 기대할 수 있음. -
트랜잭션 관리
스토어드 프로시저는 데이터베이스 내에서 트랜잭션을 관리하는 데에 유용. 복잡한 비즈니스 로직을 트랜잭션으로 묶어 일관성을 유지하고 롤백이 필요한 경우 트랜잭션을 롤백할 수 있음. -
보안 및 권한 관리
스토어드 프로시저는 데이터베이스 레벨에서 실행되므로 데이터베이스의 보안 및 권한 모델을 활용하여 접근 제어를 관리할 수 있음. -
성능 최적화
스토어드 프로시저는 데이터베이스 서버에서 미리 컴파일되고 최적화되어 있기 때문에 실행 속도가 빠르다. 특히 많은 양의 데이터를 다루거나 복잡한 계산이 필요한 경우 성능 측면에서 이점을 제공. -
데이터 정제 및 가공
데이터베이스에서 데이터를 정제하거나 가공해야 하는 경우에는 스토어드 프로시저를 사용하여 데이터를 일관되게 가공이 가능.
단점
-
데이터베이스 종속성
특정 데이터베이스 제품에 의존하며, 이로 인해 특정 데이터베이스에 강하게 결합. 이는 데이터베이스를 변경하거나 다른 종류의 데이터베이스로 이전하는 데 어려움을 초래. -
유지보수 어려움
스토어드 프로시저는 일반적으로 별도의 언어로 작성되며, 이는 일반적으로 애플리케이션 코드와 다르다. 유지보수 어려움. -
테스트 어려움
스토어드 프로시저의 테스트는 종종 어려울 수 있다. 일부 데이터베이스에서는 테스트를 위한 적절한 도구 및 프레임워크가 부족할 수 있음. -
버전 관리 어려움
스토어드 프로시저는 데이터베이스 내에서 관리되기 때문에 코드 버전 관리가 어려움. 코드 변경 사항을 추적하고 롤백하는 일이 복잡함. -
언어 제약
주로 SQL이나 특정 데이터베이스 제공 언어로 작성. 이로 인해 특정 언어의 기능이나 생태계를 활용하기 어려움. -
이벤트 기반 구조와 부적합
이벤트의 비동기적인 흐름을 처리하는 데에는 제약이 있음.
