[통신] SQL에서 저장 프로시저를 왜 사용하며, 그 장점은 무엇인가요?

제 생각에 저장 프로시저는 단순히 SQL 병합의 집합일 뿐입니다. 중간에는 약간의 논리 제어가 추가됩니다.

하지만 저장 프로시저가 더 복잡한 비즈니스를 다룰 때는 더 유용합니다.
예를 들어, 복잡한 데이터 조작이 있습니다. 프런트 데스크에서 처리한다면요. 여러 개의 데이터베이스 연결이 관련될 수 있습니다. 하지만 저장 프로시저를 사용한다면, 딱 한 번. 응답 시간 측면에서 이점이 있습니다.
즉, 저장 프로시저는 운영 효율성 향상이라는 이점을 가져다줄 수 있습니다.
게다가 프로그램은 버그 불안정성에 취약하며, 데이터베이스 문제가 없는 한 저장 프로시저도 사실상 문제가 없습니다. 즉, 보안 측면에서 저장 프로시저를 사용하는 시스템이 더 안정적입니다.

데이터가 적거나 돈과 무관한 프로젝트는 저장 프로시저 없이도 정상적으로 작동할 수 있습니다. MySQL의 저장 프로시저들은 아직 실제로 테스트되지 않았습니다. 공식 프로젝트라면 SQL Server나 Oracle 저장 프로시저 사용을 권장합니다. 데이터와 데이터 간의 작업을 할 때는 프로그램이 훨씬 빠릅니다. 면접관은 저장 공간이 있는지 물었고, 사실 면접에 온 프로그래머가 대량의 데이터를 가진 프로젝트를 했는지 알고 싶어 했습니다. 만약 훈련이 이루어지거나, 작은 프로젝트나 작은 회사라면 보관과의 접촉이 확실히 줄어듭니다.

따라서 대기업에 진입하려면 저장 프로세스에 대한 풍부한 경험 없이는 성공할 수 없습니다.

그렇다면 언제 보관함을 사용할 수 있나요? 데이터 양이 크지 않고 비즈니스 처리가 복잡하지 않은 작은 프로젝트라면 필요하지 않은가요?
틀렸다. 저장 프로시저는 대규모 프로젝트뿐만 아니라 소규모 및 중간 규모 프로젝트에도 적합하며, 저장 프로시저 사용도 매우 필요합니다. 그 힘과 장점은 주로 다음과 같은 점에서 나타납니다:
  1. 저장 프로시저는 생성 시점에만 컴파일되며, 저장 프로시저가 실행될 때마다 매번 컴파일할 필요가 없습니다. 반면 일반 SQL 문은 실행 시 컴파일되므로 저장 프로시저를 사용하면 데이터베이스의 실행 속도를 향상시킬 수 있습니다.
  2. 데이터베이스에서 복잡한 작업(예: 여러 테이블의 업데이트, 삽입, 쿼리, 삭제)을 수행할 때, 이 복잡한 작업은 저장 프로시저로 캡슐화되어 데이터베이스가 제공하는 트랜잭션 처리와 함께 사용할 수 있습니다. 이러한 연산은 프로그래밍적으로 수행될 경우 SQL 문이 되어 데이터베이스에 여러 번 연결되어야 할 수 있습니다. 저장 공간 대신 데이터베이스에 한 번만 연결하면 됩니다.
  3. 저장 프로시저를 재사용할 수 있어 데이터베이스 개발자의 작업 부담을 줄입니다.
  4. 높은 보안성으로, 지정된 저장 프로세스 사용 권한을 가진 사용자는 이 사용자만 설정할 수 있습니다.