다음을 통해 공유

프로시저 사용 시기

  • 아티클

프로시저를 사용하면 SQL 문을 애플리케이션에서 데이터 원본으로 이동한다는 사실에 따라 프로시저를 사용하는 데는 여러 가지 이점이 있습니다. 애플리케이션에 남아 있는 것은 상호 운용 가능한 프로시저 호출입니다. 이러한 이점은 다음과 같습니다.

  • 성능 프로시저는 일반적으로 SQL 문을 실행하는 가장 빠른 방법입니다. 준비된 실행과 마찬가지로 이 문은 별도의 두 단계로 컴파일되고 실행됩니다. 준비된 실행과 달리 프로시저는 런타임에만 실행됩니다. 다른 시간에 컴파일됩니다.

  • 비즈니스 규칙 A 비즈니스 규칙은 회사에서 비즈니스를 수행하는 방식에 대한 규칙입니다. 예를 들어 영업 사원이라는 제목의 사용자만 새 판매 주문을 추가할 수 있습니다. 이러한 규칙을 프로시저에 배치하면 개별 회사에서 애플리케이션 코드를 수정하지 않고도 애플리케이션에서 호출하는 절차를 다시 작성하여 수직 애플리케이션을 사용자 지정할 수 있습니다. 예를 들어 주문 입력 애플리케이션은 고정된 개수의 매개 변수를 사용하여 InsertOrder 프로시저를 호출할 수 있습니다. InsertOrder가 구현되는 방법은 회사마다 다를 수 있습니다.

  • 프로시저에 비즈니스 규칙을 배치하는 것과 밀접한 관련이 있는 대체 가능성은 애플리케이션을 다시 컴파일하지 않고도 프로시저를 대체할 수 있다는 사실입니다. 회사에서 애플리케이션을 구입 및 설치한 후 비즈니스 규칙이 변경되면 회사에서 해당 규칙을 포함하는 절차를 변경할 수 있습니다. 애플리케이션의 관점에서 볼 때 아무것도 변경되지 않았습니다. 여전히 특정 작업을 수행하기 위해 특정 프로시저를 호출합니다.

  • DBMS 관련 SQL 프로시저는 애플리케이션이 DBMS 관련 SQL을 악용하고 여전히 상호 운용 가능한 기본 방법을 제공합니다. 예를 들어 SQL에서 흐름 제어 문을 지원하는 DBMS의 프로시저는 오류를 트래핑하고 복구할 수 있지만 흐름 제어 문을 지원하지 않는 DBMS의 프로시저는 단순히 오류를 반환할 수 있습니다.

  • 프로시저는 트랜잭션을 유지합니다. 일부 데이터 원본에서는 트랜잭션이 커밋되거나 롤백될 때 연결에서 준비된 모든 문에 대한 액세스 계획이 삭제됩니다. 데이터 원본에 영구적으로 저장되는 프로시저에 SQL 문을 배치하면 문은 트랜잭션에서 유지됩니다. 프로시저가 준비됨, 부분적으로 준비된 상태 또는 준비되지 않은 상태로 유지되는지 여부는 DBMS에 따라 다릅니다.

  • 별도의 개발 절차는 애플리케이션의 나머지 부분과 별도로 개발할 수 있습니다. 대기업에서는 고도로 전문화된 프로그래머의 기술을 더욱 활용하는 방법을 제공할 수 있습니다. 즉, 애플리케이션 프로그래머는 사용자 인터페이스 코드를 작성할 수 있고 데이터베이스 프로그래머는 프로시저를 작성할 수 있습니다.

프로시저는 일반적으로 세로 및 사용자 지정 애플리케이션에서 사용됩니다. 이러한 애플리케이션은 고정 작업을 수행하는 경향이 있으며, 이를 통해 호출을 하드 코딩할 수 있습니다. 예를 들어 주문 항목 애플리케이션은 InsertOrder, DeleteOrder, UpdateOrder 및 GetOrders 프로시저를 호출할 수 있습니다.

제네릭 애플리케이션에서 프로시저를 호출할 이유가 거의 없습니다. 프로시저는 일반적으로 특정 애플리케이션의 컨텍스트에서 작업을 수행하기 위해 작성되므로 제네릭 애플리케이션을 사용하지 않습니다. 예를 들어 스프레드시트에는 멘션 InsertOrder 프로시저를 호출할 이유가 없습니다. 또한 제네릭 애플리케이션은 더 빠른 문 실행을 제공하기 위해 런타임에 프로시저를 생성해서는 안 됩니다. 준비되거나 직접 실행보다 느릴 수 있을 뿐만 아니라 DBMS 관련 SQL 문도 필요합니다.

이에 대한 예외는 프로그래머가 프로시저를 실행하고 프로그래머가 프로시저를 테스트하는 방법을 제공하는 SQL 문을 빌드하는 방법을 제공하는 애플리케이션 개발 환경입니다. 이러한 환경에서는 SQLProcedures를 호출하여 사용 가능한 프로시저를 나열하고 SQLProcedureColumns를 호출하여 입력, 입력/출력 및 출력 매개 변수, 프로시저 반환 값 및 프로시저에서 만든 결과 집합의 열을 나열합니다. 그러나 이러한 절차는 각 데이터 원본에서 미리 개발되어야 합니다. 이렇게 하려면 DBMS 관련 SQL 문이 필요합니다.

프로시저 사용에는 세 가지 주요 단점이 있습니다. 첫 번째는 애플리케이션이 실행될 각 DBMS에 대해 프로시저를 작성하고 컴파일해야 한다는 것입니다. 이는 사용자 지정 애플리케이션에 문제가 되지 않지만 여러 DBMS로 실행되도록 설계된 수직 애플리케이션의 개발 및 기본 테넌트 시간을 크게 늘릴 수 있습니다.

두 번째 단점은 많은 DBMS가 절차를 지원하지 않는다는 것입니다. 다시 말하지만, 이는 여러 DBMS로 실행되도록 설계된 수직 애플리케이션에 문제가 될 가능성이 큽니다. 프로시저가 지원되는지 여부를 확인하기 위해 애플리케이션은 SQL_PROCEDURES 옵션을 사용하여 SQLGetInfo를 호출합니다.

애플리케이션 개발 환경에 특히 적용되는 세 번째 단점은 ODBC가 프로시저를 만들기 위한 표준 문법을 정의하지 않는다는 것입니다. 즉, 애플리케이션은 프로시저를 상호 운용적으로 호출할 수 있지만 상호 운용적으로 만들 수는 없습니다.