스토어드 프로 시저에서 동적 SQL을 피하려는 이유는 무엇입니까?

Dynamic SQL을 사용하고 싶지 않다고 들었습니다. 구체적인 예나 실제 예를 들어 줄 수 있습니까? 개인적으로 데이터베이스에 몇 번 코딩했습니다. 유연성이기 때문에 괜찮습니다. 내 생각 엔 SQL 인젝션 또는 성능에 관한 것입니다. 다른 거있어?

필요한 경우 동적 SQL을 사용하는 데 아무런 문제가 없습니다. 실제로 어떤 상황에서는 이것이 유일한 옵션입니다. 입력을 위생 처리하지 않으면 SQL 삽입으로 이어질 수 있으므로 예를 사용하지 않는 것이 좋습니다. 예를 들어 호출되는 모듈에서 동적 SQL을 사용하면 성능에 해로울 수 있습니다.

나는 그 자체로 구체적인 예가 있다고 생각하지 않지만 나는 이것을 말할 것입니다 : 당신은 정기적 인 쿼리와 문장을 먼저 사용한 후에 무엇을 달성하려고 노력하십시오. 동적 SQL 문자열 실행은 호출하는 모듈에 대한 별도의 사용자 세션에서 수행되므로 예상하지 못한 권한 문제가 발생할 수 있습니다.

성능이 걱정된다면; 그것을 테스트하십시오. 보안이 걱정되는 경우 입력을 확인하십시오. 옳고 그름은 없습니다. 귀하가 당시에 이용할 수있는 정보와 도구를 바탕으로 최선의 판단을하는 것만입니다.

동적 SQL은 도구입니다. 그리고 도구로서 일부 응용 프로그램이 있습니다. 예를 들어 관리 작업의 경우 축복입니다.

생성 된 코드의 매개 변수화를 관리하지 않은 경우 특히 응용 프로그램에서 사용하는 SP에는 적합하지 않습니다 (최신 버전의 SQL Server에서는 문제가 줄어들었지만 여전히 유효합니다).

여기서는 자세하게 입력하지 않기 때문에 Dynamic SQL 문제에 대한 훌륭한 기사 인 MVP Erland Sommarskog 의 Dynamic SQL의 저주와 축복을 추천합니다.

그것은 대부분의 dbms 기능과 같습니다. 올바른 상황에서 사용하면 제대로 작동하지만 잘못 된 상황에서는 제대로 작동하지 않습니다.

장점 : 어떤 것들은 그것 없이는 할 수 없습니다. 일반적으로 응용 프로그램 코드가 아닌 관리 작업에만 사용됩니다. 일부 시스템 명령에서는 매개 변수를 입력으로 사용할 수 없습니다. 예를 들어 알 수없는 데이터베이스가있는 많은 인스턴스에서 모든 데이터베이스에 대해 sproc을 통해 무언가를 실행해야하고 명령이 매개 변수를 허용하지 않으면 일반적으로 동적 SQL을 통해이를 해결합니다. 그러나 이것은 Sybase ASE에서 MSSQL보다 더 중요합니다.

단점 : 우리 모두 이미 알고 있다고 생각하기 때문에 많이 들어가지는 않지만 SQL 주입이 잘못 사용되면 약간의 위험이 있습니다. 나에게 가장 큰 것은 쿼리가 원래 쿼리와 동일하게 처리되고 컴파일 된 쿼리 계획의 일부가 아니라는 것입니다. 때때로 실행되는 무언가에 대해서는 별 문제가 없습니다. 분당 수백 번 실행되고 고유 한 SQL이 많은 경우에는 새롭고 잠재적으로 불필요 한 쿼리 계획이주기를 차지하고 계획 캐시의 유효 시간이 단축됩니다.

동적 SQL을 사용하지 마십시오.

99 %의 저장 프로 시저에서 선택적 매개 변수를 사용하는 방법 에 대한 지식이 없기 때문에 Dynamic SQL이 사용되고 나머지 1 %는 고객이 이해하지 못하는 보고서에 대해 매우 복잡한 쿼리를 만드는 데 사용됩니다. 조차. Dynamic SQL의 저주와 축복은 왜 그것을 사용하는 것이 좋은지에 대한 예를 보여주지 않고 대신 SQL의 보안 위험을 언급하지 않고 디버깅, 유지 관리의 복잡성을 증가시키기 때문에 문제가 있음을 시사합니다. 사출, 성능 저하 때문이 아니라 캐시하지만 임시 테이블 및 커서를 사용처럼 함께 나쁜 관행 이는 물론의 게으른 하고 순진한프로그래머는 남용 할 것입니다. 그런 식으로 쿼리를 작성할 수있는 유연성과 같은 것은 없습니다. SQL은 선언적 언어이므로 처리해야합니다.

게으름은 모든 악의 근원입니다.

역설적으로이 답변은 가장 하향식 된 답변에서 순위를 매길 것입니다 .