스토어드 프로시저

학습/이론

이원숭 2023. 4. 5. 09:21

MSSQL을 사용함에 있어 중요한 Stored Procedure를 왜 사용하는 것이고, 어떠한 장단점이 있는지 알아보려고 한다.

스토어드 프로시저란?

쿼리를 함수처럼 실행하기 위한 쿼리의 집합

스토어드 프로시져는 저장 프로시저라는 뜻을 가지고 있다.

DB에 있는 데이터를 조회하기 위해서는 짧은 쿼리문 뿐만 아니라 100줄이 넘어가는 긴 쿼리를 작성해야 하는 경우가 생기는데,

작성된 쿼리문을 프로시저에 저장, 필요할 때에 프로시저를 호출 하여 효율적으로 프로그래밍 하기 위해 사용된다.

또한 IF문이나 반복문을 사용하여 프로시저를 호출 할 수 있는 것도 큰 장점이라고 생각된다.

*알고보니 프로시저는 MSSQL뿐만 아니라 MySQL에서도 사용이 되고 있었다.

장점

하나의 요청으로 여러 SQL문을 실행 할 수 있다.
- 하나의 sp안에 IF문과 반복문을 사용하여 여러 형태의 쿼리문을 작성한다.
네트워크 소요 시간을 줄일 수 있다.
- 동일한 쿼리를 1000번 2000번 호출하는 것보다 SP를 이용해서 구현한다면 SP를 호출할 때 한 번만 네트워크를 경유하기 때문에 네트워크 소요시간을 줄이고 성능을 개선할 수 있다.
개발 업무를 구분해 개발 할 수 있습니다.
- 순수한 애플리케이션만 개발하는 조직과 DBMS 관련 코드를 개발하는 조직이 따로 있다면, DBMS 개발하는 조직에서는 데이터베이스 관련 처리하는 SP를 만들어 API처럼 제공하고 애플리케이션 개발자는 SP를 호출해서 사용하는 형식으로 역할을 구분하여 개발이 가능

단점

처리 성능이 낮다.
- 문자나 숫자 연산에 저장 프로시저를 사용한다면 오히려 C나 JAVA보다 성능이 느리다.
디버깅이 어렵다.
- 너무 공감하는 부분이다.. 실제 프로시저를 작성하여 개발하면서 어떤 부분에 오류가 나고 있는지 자세하게 알려주지 않기 때문에, 프로시저 자체를 호출하면서 중간중간 실행되고 있는 결과를 찍어보면서 디버깅을 해야한다.(php처럼 디버깅 해야했던 기억이 난다)
DB 확장이 매우 힘들다.
- 서비스 사용자가 많아져 서버수를 늘려야할 때, DB 수를 늘리는 것이 더 어렵다.
- 서비스 확장을 위해 서버수를 늘릴경우 DB 수를 늘리는 것보다 WAS의 수를 늘리는 것이 더 효율적이기 때문에 대부분의 개발에서 DB에는 최소의 부담만 주고 대부분의 로직은 WAS에서 처리할 수 있게 합니다.
  (아마도 api를 호출하는 서버를 분할하여 늘리는 것을 얘기하는 것 같다..)