backend or procedure

procedure에서 처리할 때의 장단점

장점

• 역할분담을 할 때 더 자세히 나눌 수 있다. (client/backend/db&procedure)
• 프로시저를 보거나 수정할 수 있는 유저를 따로 제한해서 보안적인 측면에서 유리할 수 있다.
• 디버깅시 쿼리로 즉각 확인할 수 있다.
• 수정 후 서버 재가동없이 즉각 반영된다.

단점

• 비지니스로직이 데이터베이스에 더욱 종속적이기 때문에 유연하게 운영하기 어렵다.
• DB 컨테이너의 부하를 유발한다. (그리고 DB 컨테이너는 확장이 간단치 않고 비용이 많이드는 작업이다.)
• 결국 모든 프로그램 영역을 커버할 수는 없다. (타 API 연동 등)
• 클라이언트가 요구하는 복잡한 비지니스 요구사항을 만족하기 어렵다.
• 유지보수성이 낮다.
  • 개발 후 유지보수 단계에서 한명의 개발자가 backend와 procedure를 번걸아가며 수정해야하고 난이도가 올라간다.
  • 에러 핸들링이 불편하다.
  • 여러부분을 고치거나 변수명 변경 등의 경우에 IDE의 도움을 받기 어렵다.
  • 프로시저의 형상관리가 어렵다.

전통적인 어플리케이션-PowerBuilder, Visual Basic 같은 리치 클라이언트 어플리케이션 등-을 개발 할 때는 2-tier 아키텍처. 즉, 클라이언트에서 프레젠테이션/비즈니스 로직을 작성하고, 서버 사이드에는 데이터베이스가 위치하는 방식을 사용했다. 이런 방식은 10년 전, 20년 전에는 대세였다. 그러한 시기에 개발을 했던 개발자 일부는 현대 어플리케이션을 개발하면서 저장 프로시저에 비지니스로직을 작성하고 있다.

위에서 보다시피 2-tier 아키텍처의 다양한 단점 때문에 현재는 3-tier, N-tier 아키텍처를 사용하고 있다. 즉, 현대 개발 아키텍처에서는 (특히 웹 어플리케이션) 비지니스로직은 backend에서 모두 처리하고, DB는 순수하게 데이터만 저장하고 불러온다.

이 글을 보고 있는 대부분이 Legacy System에서 저장 프로시저에서 비지니스 로직으로 범벅되어 있는 것을 본적이 있고, 답답해 했을 것이다. 그러나 지금 당장 고치는 Legacy System을 엎으려는 생각은 하지마라, 회사입장에서도 멀쩡히 동작하는 시스템에 비용을 들일 이유가 없다. 그럼에도 불구하고 욕심이 생긴다면 구체적으로 계획을 세우고 파트별로 교체, 테스트 작업을 해야한다. 그리고 그 전에 먼저 읽어보자 Things You Should Never Do, Part I

참고자료 https://okky.kr/article/170846 https://blog.daum.net/pilgrimfortruth/2930 https://m.blog.naver.com/deepb1ue/221225901652 https://amanokaze.github.io/blog/Business-Logic-Where/ https://amanokaze.github.io/blog/Business-Logic-Where/