Egloos | Log-in
결론에 가보기
결론에 가보기
아.. 왜 SP(Stored Procedure)을 쓰는거냐고


아침부터 답답함에... 쩝

지금 진행하고 있는 프로젝트에서 SP를 쓸려고 한다.
물론 SP가 없는것은 아니지만 딱1개!!. 
그것도 데이터 넣고 빼고가 아니라 display할때 yes/no(데이터를 가지고 비트연산을 조금하고 판단하는 부분)만을 
쓰고 있었는데 지금 꽤 중요한 비지니스 로직(조건에 따라서 데이터 유무를 판단해서 insert/update/delete 하는)을
SP로 만들려고 하고 있다.

당연히 나는 디펜스를 하려고 하는데.. 힘드네..
SP를 찬성하는 사람의 주장은 아주 간단하다.
SP가 성능이 좋고 Critical한 비지니스 부분은 가는게 좋아보인다는 것이다. -_-;;;


Stored Procedure가 성능이 좋다?

그래.. 아주아주 밀리세컨드까지 비교하면 더 빠를 것이다. 당연히 DB안에서만 모든 것을 판단하고
처리하니 빠르겠지. 하지만 이 빠르고 느림은 단순한 숫자일뿐 사용자는 그 차이를 느끼지 못할정도로
미비할것이다. 사용자가 느낄정도로 차이가 있는 부분이고 쿼리 튜닝이나 다른 방법으로 해결을
못한다면 진짜로 SP로 가야 한다. 하지만 절대!!! 이러지 않을것이다.

그리고!! 요즘같은 ActiveRecord, Hibernate, iBatis등의 persistence layer도 잘 쓰고 있는 시점에
단순히 성능이 좋다라는 측면으로 SP로 간다는 것이 절대 동의할수 없다!!


관리적은 측면으로 중요한 비지니스 로직은 SP로 간다?
(이 코멘트를 한 사람도 개발자이다 -_-;;)

아.. 정말 이게 ㅠㅜ 누구의 생각인지.. 쩝.
요즘 웹쪽의 프레임웍이 왜 MVC의 모델로 많이들 사용하고 있다고 생각을 하는가..
그것은 각자 부분의 역할을 잘 나누어서 관리적인 측면의 효과를 높이기 위함이다.

지금 우리의 프로젝트처럼 기획자, 디자이너, 개발자, DBA의 역할이 잘 나눠져있는 부분에서
비지니스로직을 DBA에게까지 전달하라는 말인가? 그럼 우리 개발자의 역할은 무엇인가?
어떤 부분은 SP로 만들고 어떤것은 자바로 만들껀데? 기준없이 그냥 생각나는데로 가는거지?

안그래도 지금 비지니스 로직도 배치, front, backend로 나눠져있어서 아주 미묘한 부분에서 오류가 나면
전체를 다 뒤져야 하는데 관리포인트롤 SP까지 한가지 더 두자는건 좀 아니자너..
갈꺼면 전체 비지니스로직을 모두 다 SP로 가던지.. 

개발자의 일이 줄어든다고 좋아라 하는건가? -_-;;;; 답답하다..
by 제우스 | 2008/11/13 14:24 | 컴퓨터 | 트랙백(1) | 핑백(1) | 덧글(8)
트랙백 주소 : http://zeous.egloos.com/tb/2135418
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from at 2014/03/11 00:47

제목 : pure garcinia cambogia
line2...more

Linked at 결론에 가보기 : [잡생각] .. at 2009/05/25 11:41

... 이 글을 쓰고 싶었던 이유는 한참 전에 내가 올린 포스팅에서 시작이다.SP를 쓰는것을 반대하던 내 글에서의 댓글은 아니었지만 다른 사람의 블로그의 댓글에서 내가 SP를 반대하는것이 내가 SP를 잘 모르기때문이라는 말이 있어서였다.  내가 쿼리를 얼마나 잘 쓰는지(? ... more

Commented by JOSH at 2008/11/13 16:06
음... 저도 좀 데이터 다루는 점에서는 보수적이라...
다른건 몰라도 한꺼번에 많은 양의 데이터를 동기시켜 바꾸는 트랜잭션이 필요한 상황은
절대로 프로시저를 사용해야 한다고 고집하는 편입니다.

그리고 그 편이 개발하는데 있어서도 서로 간의 업무영역을 명확히 하고
개발중 어느 한 쪽의 에러가 전체 프로젝트에 파급될 수 있는 위험요소를 막는 장치 중 하나라고 생각해요.

물론 다 불편한거 편하게 쓰자고 개발언어 레벨에서 트랜잭션 다루고자 나온 기술들이겠지만...
일전에 쓰신 '~기술적인 문제가 아니다' 에서도 보수적이 되는 부분이 언급되었지만
신기술이라면 한 세대나 아니면 적어도 2~3년은 지나면서 버그도 없어지고 백도어의 걱정도 덜지 않을까 싶습니다.
Commented by 제우스 at 2008/11/13 16:32
JOSH 님 ^^ 저랑 의견이 조금 다르시군요.. 그래도 환영합니다.

트랜잭션부분에 있어서.. SP가 추가가 되면
자바소스 -> SP -> 자바소스로 가는 형태이고 3부분이 하나의 트랜잭션으로 지켜져야 한다면
SP는 입력하는 것과 rollback 하는 2개가 필요하게 되고 2번째 자바소스부분에서 exception이 발생하면 rollback SP를 호출하게 되죠
따라서 자바와 SP가 같이 있는 소스형태면 불편함이 높아진다고 생각이 들어서 자바소스면 자바소스, SP면 SP등
최대한 공존하지 않기를 원하는 것이죠.

JOSH님이 개발자인지 DBA인지 (느낌상 ^^ 개발자같은데요 핫핫) 잘 모르겠지만
저희는 DBA가 SP를 모두 총괄해서 재컴파일이나 추가를 쉽게 하지 못합니다.
변경사항이 생기면 DBA에게 요청해야 하고 또한 DBA에게 기획자에게서 전달받은 비지니스 로직을 잘 설명을 해줘야 하죠.
if A 가 의미하는 것은 무엇이고 이럴땐 여기 정보를 컨트롤 해야 하고..

어떤 것을 DBA에게 요청해야 하고 어떤것은 내가 개발해야 하는지 그 경계가 모호해지는것이 더 힘들지 않을까 해요
데이터양이 많은것? 데이터가 많다는것은 몇건정도를 봐야 하나..

그리고 재활용이 충분히 가능한 SP를 만드는것이 결국 객체지향으로 가는 것을 의미하는게 아닐까 생각이 듭니다.

ps. 그리고 ^^ 제가 데이터를 컨트롤 하는 부분을 Hibernate나 iBatis로 가자고 하는게 아니라
그냥 SQL로 가자고 하자고 ^^ 하는 정도입니다 핫핫.
Commented by JOSH at 2008/11/13 16:57
네.. 전 개발자에 가깝습니다. ^^;

제가 뭐 개발경력이 제우스님만큼 되지도 않고,
기획, 관리, DB테이블조작, 개발 등등을 다 찝적거리다 보니 핫핫..
지금은 SI관련 업무를 하다 보니까
은행 이나 비용 등 금융관계 데이터를 다루는 개발도 종종 하고 있습니다.

'많다'는 개념은 그냥 한꺼번에 여러 부분을 건드린다는 느낌으로 말씀드린 겁니다.

트랜잭션이 원하는게 '도 아니면 모'니까, 동기가 필요한 어느 단위업무를 설정하고 던져주는건 개발 단,
그게 되냐 마냐를 결정하는건 DB 단 이라고 보면 더 책임이나 역할분담이 명료하지 않나 하는거죠.

굳이 당연한 내용을 언급한게...
그당시 회의의 느낌은 모르겠습니다만
(속도를 성능의 기준으로 본다... 면 길은 여러가지가 있겠지요.)
속도는 둘째 치고 DB에서 가장 중요하게 생각해야 하는게 데이터의 신뢰성이라면
SP가 어떤 것보다 트랜잭션의 기본 아닐까 싶다... 는 의견입니다만
신기술을 받아들이는것에 거부감을 가지는게 역시 너무 보수적인 자세이기도 하죠.

아무래도 금융관련 업무를 자주하셨던 분이나 과거 포트란코볼 을 주로 만져서
개발쪽 기술이 지금처럼 풍요롭지 않은 시절부터 활동하셨던 분이라면
SP에 대해 절대적인 신뢰를 가지고 계실거고... ^^

저도 처음 개발 배우던건 90년대라서 그런 거 같습니다...
Commented by 오리대마왕 at 2008/11/13 17:40
제우스님, 근데
"트랜잭션부분에 있어서.. SP가 추가가 되면
자바소스 -> SP -> 자바소스로 가는 형태이고 3부분이 하나의 트랜잭션으로 지켜져야 한다면
SP는 입력하는 것과 rollback 하는 2개가 필요하게 되고 2번째 자바소스부분에서 exception이 발생하면 rollback SP를 호출하게 되죠"

이 부분은 SP도 자바측에서 하나의 transaction 으로 물리게 만들 수 있으니 잘못 된 표현 아닌가요? SP 내부에서 commit 하지 않는다면, 자바<->SP 왔다갔다 한다고 transaction 을 분리할 필요는 없다고 생각합니다. 따라서 rollback SP가 별도로 필요하지도 않고요. (아닌가? 히히)

한가지 궁금한 점은, SP를 만드는 것이 DBA의 role이라는 가정이 SP 사용을 반대하는 이유 중 하나인가요? 만약 개발자가 SP를 개발한다면 어떻게 생각하세요?

저도 비즈니스 로직에 대한 관리point 가 늘어난다는 점에서 SP라는 녀석 하나를 더 끌고 가는 것이 참으로 부담되는 일이라고 생각하지만, 또 SP는 SP 나름대로 써야 할 곳이 있을 테니 (앞서 제우스님도 이미 하나의 SP는 돌리고 있다고 하셨으니까요) 현재 상황을 정확히 알 수 없는 상황에서는 모르겠지만, 막연히 반대하기는 힘들지 않나 생각합니다.
Commented by 나기드 at 2008/11/13 17:55
아아~

SP를 하나만 써도 해결되는 상황이 있다면 정말 행복하네요... ???


어차피 쓰냐 안쓰냐는 효율과 유지보수비용 아닐까요?
정량화해서 - 효율에 100원, 유지보수비용에 90원 식으로.. - 선택하면 됩니다.

어차피 유지보수비용이라는 게, 정말 장난이 아닙니다.
한번 쓰고 버릴거라면, 그냥 다른 사람들이 하는 것 들어주세요.
어차피 개발자는 혼자 살아가면 안됩니다.

혼자 아무리 잘짜도, 타인을 이해시키지 못하면 반쪽짜리 예술가(?) 입니다.
Commented by 제우스 at 2008/11/13 18:04
JOSH// JOSH님 정도면 저보다 훨씬 경험이 많으신데요..머
님처럼 멀티로 다 컨트롤 할수 있는 분이라면 선택에 존중을 해드리죠..
SP를 원하는 개발자는!!! SP를 짤수 없는 사람이기에 -_- 그냥 일 넘기는 것이라.. 제가 불끈 했네요.. 핫핫

오리시마//
아.. SP에서 commit을 안하는것이 같은 트랜잭션으로 처리가 되는지 잘 모르겠네요.. 함 해봐야겠다.
그리고 위에서도 썼지만.. 전 SP 만들자나요.. 못 만드는 사람들이 SP로 가야 한다고 주장하는게.. 쩝.. 좀 그려요..
DBA의 롤인것도 좀 그렇고.. 개발자가 자유롭게 컨트롤 가능하다고 해도.. 전!! 자바나 루비쪽으로 가져옵니다.
그래야 이클립스에서 검색하면 한번에 나오기에..쿨럭.

나기드//
계속 유지보수를 해야 하는 부분이기에 관리포인트를 줄이고 싶은것이죠..머
한번 데이터 보정 작업으로 만드는거야..머 어떤것으로 하던지.. 문제가 되겠습니까.

Commented by JOSH at 2008/11/13 19:28
> 아.. SP에서 commit을 안하는것이 같은 트랜잭션으로 처리가 되는지 잘 모르겠네요.. 함 해봐야겠다.
> 그리고 위에서도 썼지만.. 전 SP 만들자나요..

아.. 그럼 다른 이 글을 보는 분들을 위해서 그냥 간단히 만 ...
SP의 목적은 DB를 위해 특화된 펑션이나 메서드라는 거는 아실테고,
이 놈은 다른 것과 틀린게 바로 저 커밋과 롤백을 위해 존재한다고 해도 과언이 아니지요.

그래서 일반적인 구조는 아래와 같이 됩니다.

"너 이 일 해. 조건은 이렇다. ' X Y Z 던져주니까 결과적으로 X'테이블의 A,B,C,D Y'테이블의 E,F,G,H Z'테이블의 I,J,K,L 에 있는 데이터들 서로 이러이러하다는 조건하에 비교하고, 계산해서 조합하고, 그걸 어디던져넣어' ... "그.런.데." 이 업무동안 조건 정해진 거 변동있으면 안되고 하나라도 실패하면 안돼. 만약 하다가 그거 바뀌면 전부 없던 일로 하고 원복시켜"

DB 자체가 아닌 다른 쪽에서 데이터를 컨트롤 할 때는 이 조건 맞추기가 꽤 까다롭습니다.
극단적인 경우 바깥에서 어떤 주체가 특정 DB의 데이터를 잡고 자기일 끝날 때까지 안 놔주는 상황을 얼마간 견뎌야 하는지 모르게 되는 끔찍한 사태도 발생할 수 있으니까요.

그래서 대부분의 프로시저는 끝날 때

........ EXCEPTION WHEN OTHERS THEN
av_ret_code := 'FAILURE!';
av_ret_message := F_FRM_ERRMSG_C('생성시 에러발생',
v_program_id, 0002, sqlerrm, an_mod_user_id
);

rollback;
return;
END;

/* *********************************************************** */
/* 작업완료 */
/* *********************************************************** */

--COMMIT ;

av_ret_code := 'SUCCESS!';
av_ret_message := F_FRM_ERRMSG_C('프로시져 실행 완료..',
v_program_id, 0090, null, an_mod_user_id);

END;

이렇게 '만약 에러발생 하면 롤백시키고 실패메시지 내, 아니면 커밋하고 성공메시지 내고 끝'
이라는 마무리를 짓게 됩니다.
프로그래머가 SP내에 있었던 어떤 작업도 어떤 신경도 안 쓰고 rollback 한마디로
'없었던 걸로 해주세요~' 라고 끝낼 수 있다는게 SP의 이쁜 점이고
DB바깥의 언어들이 환경에 따라 이리저리 바뀌기도하고, DB를 만져 줄 다른 기술이 없었던 시절
이거 만으로 몇십년을 살아온 분들께는 SP 만한 친구가 없지요....
Commented by 나도개발자 at 2015/04/23 22:59
sp를 싫어하는 개발자들은 유지보수핑계를 대지만 대부분 sql실력이 별로인 개빌자가 많은듯해요

:         :

:

비공개 덧글

◀ 이전 페이지 다음 페이지 ▶

카테고리
영화나 책
말말말
컴퓨터
게임이야기
태그
서버개발 보험 helloworld 하이코드 원리 파워코드 웹개발자 마이너코드 vanish 스테가노그래피 재태크 ngrinder 개발 게임 제이슨프라이드 디아블로3 메이저코드 슬럼프 나꼽살 기타코드 직업 2nd밴드 ror 공연 오픈세미나 똑바로일하라 개발자 화성학 라이프사이클
전체보기
최근 등록된 덧글
다자가이든 소작이든 닭이 천 마리..
by yada at 09/20
나는 팔라독 헬 깸.
by 남영찬 at 06/17
^안녕.하세요^;; 골드팟 생기개..
by 전설의레전드소설책 at 03/25
이왕이면---- A7 등등 '7' 이 붙는..
by papagoat at 04/12
매우 감사합니다 ! 아주 쉽게 키..
by papagoat at 04/12
자꾸 F를 라로 표기하시네요 ㅎㅎ
by 안녕하세요 at 12/21
시 클라식 기타 코드표 도 보여..
by 강초보 at 06/08
sp를 싫어하는 개발자들은 유지..
by 나도개발자 at 04/23
여자친구와의 금연약속을 어겨서..
by 구사일생 at 11/13
D코드 5번줄과 3번줄의 라를 이야..
by 제우스 at 10/15
라이프로그
똑바로 일하라
똑바로 일하라

펜트하우스 코끼리
펜트하우스 코끼리

화폐전쟁
화폐전쟁

10억
10억

거북이 달린다
거북이 달린다

용의자 X의 헌신
용의자 X의 헌신

마더
마더

터미네이터 : 미래전쟁의 시작
터미네이터 : 미래전쟁의 시작

스타트렉 더 비기닝
스타트렉 더 비기닝

천사와 악마
천사와 악마

노잉
노잉

7급 공무원
7급 공무원

박쥐
박쥐

인사동 스캔들
인사동 스캔들

와이키키 브라더스
와이키키 브라더스

매란방
매란방

건투를 빈다
건투를 빈다

코끼리는 생각하지 마
코끼리는 생각하지 마

배려
배려

벤자민 버튼의 시간은 거꾸로 간다
벤자민 버튼의 시간은 거꾸로 간다

작전
작전

워낭소리
워낭소리

작전명 발키리
작전명 발키리

적벽대전 2 : 최후의 결전
적벽대전 2 : 최후의 결전

트랜스포터 - 라스트미션
트랜스포터 - 라스트미션

디파이언스
디파이언스

사랑하지 않으면 떠나라!
사랑하지 않으면 떠나라!

촐라체
촐라체

쌍화점
쌍화점

황후화
황후화

크리스마스 별장
크리스마스 별장

눈먼 자들의 도시
눈먼 자들의 도시

예스맨
예스맨

순정만화
순정만화

펀치 레이디
펀치 레이디

눈에는 눈 이에는 이
눈에는 눈 이에는 이

전략적 책읽기
전략적 책읽기

돈, 뜨겁게 사랑하고 차갑게 다루어라
돈, 뜨겁게 사랑하고 차갑게 다루어라

좋은 놈, 나쁜 놈, 이상한 놈
좋은 놈, 나쁜 놈, 이상한 놈

다크 나이트
다크 나이트

H2 1
H2 1

그림으로 읽는 생생 심리학
그림으로 읽는 생생 심리학

호모 코레아니쿠스
호모 코레아니쿠스

강철중: 공공의 적 1-1
강철중: 공공의 적 1-1

이채원의 가치투자
이채원의 가치투자

쿵푸 팬더
쿵푸 팬더

카불의 사진사
카불의 사진사

인디아나 존스 4 - 크리스탈 해골의 왕국
인디아나 존스 4 - 크리스탈 해골의 왕국

시골의사의 부자경제학
시골의사의 부자경제학

종자돈 700만 원으로 부동산 투자 200억 만들기
종자돈 700만 원으로 부동산 투자 200억 만들기

우리동네
우리동네

디지로그 digilog
디지로그 digilog

대하소설 주역 4
대하소설 주역 4

읽지 않은 책에 대해 말하는 법
읽지 않은 책에 대해 말하는 법

Stick 스틱!
Stick 스틱!

색즉시공 시즌 2
색즉시공 시즌 2

바르게 살자
바르게 살자

20대는 통장을, 40대는 인생을 채워라
20대는 통장을, 40대는 인생을 채워라

점퍼
점퍼

생로병사의 비밀
생로병사의 비밀

추격자
추격자

오늘의 거짓말
오늘의 거짓말

주식시장을 이기는 작은책
주식시장을 이기는 작은책

대한민국 진화론
대한민국 진화론

무방비 도시
무방비 도시

피라니아 이야기
피라니아 이야기

우아한 세계
우아한 세계

경제를 읽는 기술
경제를 읽는 기술

실용주의 프로그래머
실용주의 프로그래머

블로그 비즈니스
블로그 비즈니스

어거스트 러쉬
어거스트 러쉬

세븐데이즈
세븐데이즈

뷰티풀 선데이
뷰티풀 선데이

괴물 1
괴물 1

킹덤
킹덤

당신과 일하기 힘들어 죽겠어
당신과 일하기 힘들어 죽겠어

뉴욕의 프로그래머
뉴욕의 프로그래머

나를 바꾸는 데는 단 하루도 걸리지 않는다
나를 바꾸는 데는 단 하루도 걸리지 않는다

벽오 금학도
벽오 금학도

해바라기
해바라기

펀드투자가 미래의 부를 결정한다
펀드투자가 미래의 부를 결정한다

상식이 통하는 웹사이트가 성공한다
상식이 통하는 웹사이트가 성공한다

아버지의 가계부
아버지의 가계부

본 얼티메이텀
본 얼티메이텀

최강 로맨스
최강 로맨스

여자도 여자를 모른다
여자도 여자를 모른다

부동산 10년 대폭락 시나리오
부동산 10년 대폭락 시나리오

아키텍트 이야기
아키텍트 이야기

보물지도
보물지도

오션스 13
오션스 13

게임회사 이야기
게임회사 이야기

바람피기 좋은 날
바람피기 좋은 날

조폭 마누라 3
조폭 마누라 3

삼미 슈퍼스타즈의 마지막 팬클럽
삼미 슈퍼스타즈의 마지막 팬클럽

광기와 우연의 역사
광기와 우연의 역사

런어웨이
런어웨이

회사가 당신에게 알려주지 않는 50가지 비밀
회사가 당신에게 알려주지 않는 50가지 비밀

롱테일 법칙
롱테일 법칙

해리 포터와 불사조 기사단
해리 포터와 불사조 기사단

사소한 것에 목숨 걸지 마라 - 습관 바꾸기 편
사소한 것에 목숨 걸지 마라 - 습관 바꾸기 편

우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해
우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해

트랜스포머
트랜스포머

20대부터 시작하는 스트레스 제로기술
20대부터 시작하는 스트레스 제로기술

미운오리새끼의 출근
미운오리새끼의 출근

캐리비안의 해적 : 세상의 끝에서
캐리비안의 해적 : 세상의 끝에서

미녀는 괴로워
미녀는 괴로워

유태우 교수의 내몸개혁 6개월 프로젝트
유태우 교수의 내몸개혁 6개월 프로젝트

브레이크 업 : 이별후애(愛)
브레이크 업 : 이별후애(愛)

인사이드 맨
인사이드 맨

마키아벨리, 회사에 가다
마키아벨리, 회사에 가다

웹 2.0 경제학
웹 2.0 경제학

한반도
한반도

연애, 그 참을 수 없는...
연애, 그 참을 수 없는...

구미호 가족
구미호 가족

럭키 넘버 슬레븐
럭키 넘버 슬레븐

찰리와 초콜릿 공장
찰리와 초콜릿 공장

아파트
아파트

레전드 오브 조로
레전드 오브 조로

rss

skin by jiinny
X