프로시져 만들때의 철칙

다음 내용은 절대적인 것은 아님을 밝혀둔다.

예전에 우리 회사 대리가 밑에 개발자들 참고하라고 살짝 간단히 정리해 준건데..
살짝 코멘트를 달아 보았다.

참고하면 괜찮을듯..

다 아시는 내용이지만 Procedure 사용에서 락 발생 다수 시 조치 사항입니다

1. TEMP 테이블 사용을 제한 - TEMP테이블의 경우 부하가 많은경우 락 발생이 급격하게 늘어나기 때문에 사용은 최소화 한다.
->
사실 그닥 좋은 방법이 아님은 누구나 다 알것이다.
다량의 DB작업을 하면서 임시로 쓰는것은 뭐 괜찮지만.
프로시져나 프로그램 내에서 Temp 테이블을 사용하는것은 결코 좋은 방법이 아니다.

2. 다이나믹 쿼리의 제한 - 차라리 조회 조건에서 select 을 전부 써버리는 것이 더 났습니다.
->
이 부분은 노코멘트..
사실 뭐가 성능향상에 좋은지 잘 모르겠다.
실상 테이블명이나 필드명등의 객체명이 유동적일때 다이나믹 쿼리를 자주 사용하는데..
걍 select를 다 해줘버려라.. 훔....
말했던대로 노코멘트.


3. 함수를 사용할 경우 다수의 값을 받아오는 경우에는 함수를 사용하기보다도 JOIN사용이 더 낫습니다.

함수를 사용할 경우 2건 이상인 경우에는 1건 1건씩 리턴값을 주기 때문에 리턴값이 늘어날 경우 점점 더 느려지게 됩니다.
->
예를 들어서 사번을 가지고 이름을 가져오고 메일주소를 가져올때..
보통 사번과 이름, 이메일 주소는 하나의 테이블에 있을것이다.
사원테이블 조인해서 이메일 주소와 이름을 가져오면 되는데.
함수를 사용하면 사원테이블에 접속해서 이름을 가져오고, 또 사원테이블에 접속해서 이메일 주소를 가져와야 한다. 두번 접속하게 된다.
당근.. 성능에는 치명적이다.



4. 잘 쓰지 않고 건수가 적더라도 테이블에는 반드시 인덱스를 잡는다. 실 예로 8건 밖에 안되는 코드성 테이블에 인덱스 잡는 것으로 전체 시스템 성능이 5-6배가 된 경우도 있습니다.
->
뭐 다들 알테니깐..

하지만 트랜젝션 처리가 빈번한 테이블에 인텍스는 치명적이라는 것도 알테고..

뭐 적당히 테이블 분위기 봐서 블루스를 추던 탱고를 추던 살사를 추던 해야 겠지..