Stored Procedure 코드로 옮기는 고도화 과정에서 발생한 의문을 정리한 글입니다.

Stored Procedure에 대한 정리

적절한 상황에서 적절한 기술을 쓰는 것은 찬성이다 하지만 적절한 이유 없이 쓰는 것은 잘못되었다고 생각합니다.

기존 회사 시스템이 전부 sp로 되어있었는데

제가 공부를 한 내용으로는 구조자체가 이해가 안되고, 아무리 생각해도 좋은 구조가 아니며, modern 방식이 아니라는 생각에 정리를 좀 해 보았습니다.

• 사용상의 이점
  • 클라이언트 서버 프로그램이 설치되던 시절에는 사용 할 수 있다.
    • 배포하는 코드를 수정하면 무조건 새로 다운로드 후 설치(또는 배포) 하여야 하기 때문에
  • 운영상에 장점은 있다 (DBA가 좋아한다는 말이..)
    • 수정사항이 있을 경우 SP만 수정하면 된다.
    • DB쪽에서 컴파일되어 실행되어 캐쉬 된다.
    • 자주 호출할 경우 성능 및 속도의 이점이 있다.
    • 마찬가지로 DB의 부하가 적어질 수 있다.
  • 서비스 로직이 SP에 있다.
    • 하나의 SP를 호출 하는 것으로 끝나서 상대적으로 코드 수는 간결 해 진다.
• 사용상의 단점
  • 디버깅이 어렵다.
  • 마찬가지로 테스트도 어렵다 (코드레벨에서의 테스트는 불가.)
  • 로직이 추가될 경우 SP의 line 수는 계속 늘어난다.

• 결론

  • 웹에서는 오래된 시스템에이나 SI에서는 사용되어지는데 전혀 확장성이나 유지보수를 고려하지 않은 사용성이라고 생각한다.
  • 확장성있는 구조, 책임경계를 명확히 나누어서 처리하는(Layerd Arcitecture)와 정확히 상반되는 구조인 거 같다.
  • 서비스 로직이 나위어져 있다보니까 시간이 흐른 뒤, 여러 담당자를 지나오면 History 파악도 되지 않는다.

---