Chapter 14. 스토어드 프로그램
14.1 스토어드 프로그램의 장단점
장점
- 데이터베이스 보안 향상: 자체적인 보안 설정, 스토어드 프로그램 단위로 실행 권한 부여 가능
- 기능의 추상화: 예를 들어, 일련번호(타임스탬프 + 정수)를 MySQL에서 발급하면 개발 언어나 도구와 관계없이 활용 가능 -> 반대로 말하면 일련번호 정책이 바뀌면 스토어드 프로그램을 변경해야함
- 네트워크 소요 시간 절감:
애플리케이션 <-> 데이터베이스 간의 네트워크 경유시간 >> 쿼리 실행시간인 경우에 유리 - 절차적 기능 구현: SQL에서 제공하지 않는 절차적 기능 제공(IF, WHILE 등)
- 개발 업무의 구분: 애플리케이션 개발 조직과 DBMS관련 코드 개발 조직을 분리 가능 -> 이미 많은 회사에서 DBA와 애플리케이션 개발자의 역할과 경계가 통용되므로 오히려 단점이 될 수 있음
단점
- 낮은 처리 성능: MySQL 서버는 절차적 코드 처리 성능이 떨어짐
- 애플리케이션 코드의 조각화: 애플리케이션의 설치 및 배포가 복잡, 유지보수도 어려움
- 디버깅이 어렵다 (by Jane)
14.2 스토어드 프로그램의 문법
스토어드 프로시저
- 여러 쿼리를 하나의 그룹으로 묶어서 독립적으로 실행하기 위해 사용
스토어드 함수
- 하나의 SQL 문장으로 구현해야 할 때 사용
- SQL 문장의 일부로 사용할 수 있음(스토어드 프로시저는 x)
- 5.7까지는 단일 SQL 문장으로 작성할 수 있는 방법은 없음
- 활용: GROUP BY의 SELECT절에 여러개를 합치는 경우
2명의 사원 번호만 SELECT하고 문자열로 결합하려면 스토어드 함수없이 어떻게?
트리거
- 데이터 변화가 발생할 때 실행되는 스토어드 프로그램
- 활용: 유효성 체크, 복사 및 백업, 계산 결과를 업데이트 등
이벤트
- 특정 시간에 스토어드 프로그램을 실행하는 스케줄러 기능
Q) @Scheduled vs cron? Q) 쉘 스크립트 vs 파이썬 및 Golang 스크립트, 쉘 스크립트 활용 전망? Q) RDB가 아니라면, MongoDB 에서는?
SQL의 문법을 확장해서 스토어드 프로그램의 기능을 일부 포함할 정도가 된다면 사용할만할 것 같다.
PostgreSQL의 vacuum이슈가 성능의 병목을 유발하는 경우가 있어서 MySQL로 이전중 애플리케이션은 로드가 많지만 DB는 하나만 띄워놓고 사용하는 경우가 많으므로 DB에 부하가 과중될수도 있어서 스토어드 프로그램을 안 쓰는것 같다. 스토어드 함수는 반복되는 조회의 경우 활용할만한 것 같다.