스토어드 프로시져를 사용하는 이유는요. 별거 없습니다.

연산을 위해 많은 데이터를 클라이언트로 끌고올 필요가 없다는 것입니다.

그러니까 예를 들자면 상품을 하나 매입을 하면 거기에 따라서 여러가지 처리가 발생됩니다.

매입을 기록하고, 상품 재고를 증가 시키고, 거래처의 외상 매입금을 증가시키고, 그외 다른 장부에

기록할 사항을 기록하게 되지요.

만약에 스토어드 프로스져를 사용하지 않는다면 클라이언트 프로그램에서 매입을 기록하는 Insert 문을

날리고, 그다음에 상품 재고 Update 문 날리고, 외상 매입금 증가 Update 날리고, 그외 장부에 Update,

Insert 문을 날리게 되겠죠. 그러면 서버는 날라 온걸 받아야 하고 그걸 인식 해서 다시 실행하고,

그 결과들을 또 하나씩 날려야 할 겁니다.  

물론 트리거를 사용해도 되겠지만 결국 그것도 스토어드 프로시져의 일종이니...

하지만 스토어드 프로시져를 사용하면 하나의 프로시져에서 모두 처리를 하게 되므로, 그냥 생각해 봐도

통신 부분의 시간이 줄고 결과도 하나로 날라오니 그 시간도 줄겠죠.

그리고 인식하는데도 시간이 줄고 이래 저래 시간이 줄게 됩니다. 이런 스토어드 프로시져의 효과는 작은 데이

터 보다는 많은 량의 데이터를 가지고 작업할때 그 효과를 느끼게 됩니다...

^^; 답변이 됐는지 모르겠네요... 그럼..

간단하게 생각하시면 됩니다.

두가지 기준으로 스토어드 프로시져를 사용합니다.

1.같은 sql 문장이 동일시간에 몇번이나 반복되는가?
2.컴파일시 오래 걸리는 문장.

배치작업을 스토어드 프로시져로 한다는 이야기는 대부분의 배치 작업이
같은 sql을 사용하기 때문에 1번 항목에 걸립니다. 하루에 한번이라고 해도
장기적으로 보면 많기 때문이죠..

스토어드 프로시져는 컴파일 시간을 절약하고자 하는것이지
Data input/output 시간이 줄어드는것은 아닙니다.

서브쿼리 등이 있을때 in/output에 대한 흐름도 고려를 해야 합니다.


그리고, 스토어드 프로시져는 컴파일 된 상태입니다.

그렇죠. 서버가 좀 무거워 지겠죠..

하지만 미리 컴파일을 해놨기때문에 속도는 훨씬 빠릅니다.

스토어드 프로시져 하나만 보고 써야 되나 말아야 되나를 결정하기는 그렇고

전체 시스템의 균형을 생각해서 설계 되어야 겠지요...

간단 한것들은 쿼리로 날려주고..

배치작업들이라던지 속도가 오래 걸리는 작업들을 스토어드 프로시져로 만들면

효과를 볼수 있겠죠..

sql상의 컴파일된 프로시저와 stored proc 콤포넌트에 올려서 사용하는 경우의 차이점이 어케 되는지요 ?

sql에서 storedprocedure 는 compile 이라기보다 parcing 이 아닌가요?

죄송합니다. 질문인지 답변인지 애매하네요 ㅡㅡ;;