스토어드 프로시저 질문 있습니다!!

MS-SQL에서 Stored Procedure의 사용은 예전부터 권장되어 온 방식이고 DBMS의 관점에서 바라보면 실행 계획의 재활용, 백엔드 서버에 execute 권한만 노출하는 보안 우수성, 주고 받는 네트워크 트래픽의 감소, 성능 병목의 감지와 같은 여러 장점 때문에 SP는 반드시 사용해야 하는 것이었습니다. 하지만, MySQL이나 MariaDB는 SP의 성능 상의 잇점이 미묘하여 예전부터 잘 사용하지 않았고, 오늘날에는 RDB에서 SP를 아예 사용하지 않는 것이 좋다는 인식이 확산되고 있습니다. 충분히 그럴만한 이유들이 있지만, SP 그 자체가 나쁜 것인가? 하는 것은 다시 생각해 봐야 합니다. 만약 자바라는 언어를 스프링과 같은 프레임워크 없이 사용한다면 어떻습니까? 유지보수가 어렵고, 협업이 어렵고, 생산성과 성능이 나쁜 백엔드가 만들어지겠죠. 그렇다고해서 자바가 나쁜 언어인가요? SP도 비슷한 관점으로 바라볼 수 있습니다. SP 자체는 훌륭한 기술이지만, 개발자가 훌륭하게 사용할 수 있게 해주는 프레임워크의 부재가 문제입니다. 그래서 앞으로도 뭔가 좋은 SP만의 프레임워크가 등장해 주지 않는다면, SP가 회생하는 일은 없을 거라 생각합니다. 이런 부분이 왜 아쉬운가 하면.. SP의 진정한 가치는 레포지토리 패턴을 적용할 때 나타나기 때문입니다. SP가 레포지토리 레이어를 담당하면, 비로소 백엔드와 RDBMS의 결합이 느슨해 질 수 있습니다. ORM과 같은 기술은 백엔드와 RDBMS를 한 몸으로 묶어 버려서.. DB의 형상 관리가 백엔드에 종속되어 버리는데, 이미 이런 개발 환경이 보편적이고 익숙하기 때문에 이에 대한 문제 의식이 별로 없는 것 같습니다. SP가 백엔드와 RDBMS 사이에 추상화된 레이어를 제공하게 되면, 백엔드 서비스에 영향을 주지 않고 DB를 독립적으로 형상 관리하고 배포할 수 있습니다. 이런 느슨한 결합은 DB 구조 변경에 대한 부담을 줄여주기 때문에, 비즈니스 로직의 잦은 변경을 DB 구조 변경이라는 정공법으로 해결할 수 있게 해주고, 그 결과로 DB 구조의 결함으로 인한 기술 부채를 막는데 기여할 수 있습니다.

스토어드 프로시저의 장점보단 단점이 훨씬 많다고 느껴집니다. 장점: 처리가 빠른 편이고 한번의 요청으로 많은 비즈니스 로직을 처리할 수 있다. 단점: 유지보수가 어렵다. - 스토어드 프로시저의 언어,문법을 따로 공부해야된다 - 많은 비즈니스 로직이 합쳐져 있어서 파악하기 어렵다 (가독성 떨어짐) 의존성 - 인프라스트럭처(e.g. RDBMS)에 의존적이라 DBMS 종류나 버전이 변경되는 데 제약이 걸린다 트랜잭션 처리 - 스토어드 프로시저에서 여러 비즈니스 로직을 한꺼번에 처리하다보면 여러 테이블에 동시 다발적으로 접근하여 CUD 처리 할 수 있는데 이 때 애플리케이션에서 관리하는 트랜잭션과 독립적으로 수행하기 때문에 제어하기 쉽지 않습니다. 이것은 결국 DB Lock 으로 이어질 가능성이 높아서 서비스에 치명적 일 수 있습니다. 스토어드 프로시저는 작은 시스템에서 단순하고 빠른 처리를 할 때, 비즈니스 로직의 수정이 거의 없다고 판단될 때 사용을 고려해볼 순 있을 것 같습니다.