SQL 2005+에서는 TSQL 저장 프로시저보다 CLR 저장 프로시저가 선호됩니까?

https://stackoverflow.com/questions/58190

09-06-2019
|

문제

내 현재 견해는 '아니요'입니다. Transact SQL 저장 프로시저는 더 가볍고 성능이 더 높은 옵션이므로 선호하는 반면, CLR 프로시저는 개발자가 모든 종류의 문제에 대처할 수 있도록 해줍니다.

그러나 최근에는 매우 잘못 작성된 TSQL 저장 프로세스를 디버깅해야 했습니다.평소와 마찬가지로 실제 TSQL 경험이 없는 원래 개발자로 인해 많은 문제가 발생했으며 이는 ASP.NET/C#에 중점을 두었습니다.

따라서 CLR 절차를 사용하면 먼저 이러한 유형의 개발자에게 훨씬 더 친숙한 도구 집합을 제공할 수 있으며, 두 번째로 디버깅 및 테스트 기능이 더 강력해집니다(예: SQL Management Studio 대신 Visual Studio).

간단한 선택이 아닌 것 같으니 여러분의 경험을 듣고 싶습니다.

해결책

잘 작성되고 신중하게 고려된 T-SQL과 CLR을 모두 사용할 수 있는 장소가 있습니다.일부 함수가 자주 호출되지 않고 SQL Server 2000에서 확장 프로시저가 필요한 경우 CLR이 옵션이 될 수 있습니다.또한 데이터 바로 옆에서 계산과 같은 작업을 실행하는 것도 매력적일 수 있습니다.그러나 새로운 기술을 도입하여 나쁜 프로그래머를 해결하는 것은 나쁜 생각처럼 들립니다.

다른 팁

CLR 저장 프로시저는 집합 기반 쿼리를 대체하기 위한 것이 아닙니다.데이터베이스를 쿼리해야 하는 경우 일반 코드에 포함된 것처럼 SQL을 CLR 코드에 삽입해야 합니다.이것은 노력낭비일 것이다.

CLR 저장 프로시저는 다음 두 가지 주요 용도로 사용됩니다.1) 파일 읽기 또는 MSMQ에서 메시지 삭제와 같은 OS와의 상호 작용, 2) 특히 계산을 수행하기 위해 .NET 언어로 작성된 코드가 이미 있는 경우 복잡한 계산 수행.

SQL Server 내에서 CLR을 호스팅하는 것은 데이터베이스 개발자에게 더욱 유연한 옵션 그들이 어떻게 임무를 완수하려고 노력했는지.다른 사람들이 언급했듯이 SQL은 작업 및 수정에 적합합니다. 데이터 세트.복잡한 비즈니스/도메인 규칙을 사용하여 광범위한 대규모 애플리케이션 개발을 수행한 사람이라면 누구나 순수 SQL(때때로 단일 매크로 쿼리)을 사용하여 이러한 규칙 중 일부를 적용하려고 하면 정말 악몽이 될 수 있다고 말할 것입니다.

절차적 또는 OO 방식으로 더 잘 처리되는 특정 작업이 있습니다..NET 코드를 사용하여 논리 시퀀스를 분류하면 쿼리 작업을 더 쉽게 읽고 디버그할 수 있습니다.CLR 저장 프로세스를 사용하면 디버거를 단계별로 실행하면 데이터베이스 수준에서 발생하는 상황을 따라가는 것이 실제로 더 쉬워진다는 것을 알 수 있습니다.

한 가지 예를 들면, 여기서는 동적 검색 쿼리를 위한 "게이트웨이"로 CLR 저장 프로세스를 자주 사용합니다.최대 30개의 서로 다른 검색 매개변수를 포함할 수 있는 검색 요청을 가정해 보겠습니다.사용자는 분명히 이 중 30개를 모두 사용하지 않으므로 전달된 데이터 구조에는 30개의 매개변수가 있지만 대부분 DBNULL이 있습니다.클라이언트 측은 옵션 없음 명백한 보안상의 이유로 동적 문을 생성합니다.결과 동적 명령문은 외부 "추가"에 대한 두려움 없이 내부적으로 생성됩니다.

일반적으로 데이터베이스와 많이 인터페이스할 필요가 없는 항목이 있는 경우 CLR을 사용합니다.따라서 값을 구문 분석하거나 디코딩한다고 가정해 보겠습니다.CLR에서 이 작업을 수행한 다음 값을 반환하는 것이 더 쉽습니다.

CLR에서 복잡한 쿼리를 수행하는 것은 좋은 방법이 아닙니다.

그런데 이것은 2008년에도 변하지 않았습니다.

나는 그 둘이 동일하지 않다고 생각합니다 ...서로 맞붙을 정도로 맞음.
CLR 통합은 예전의 "확장 저장 프로시저"를 단계적으로 폐지할 예정입니다. 우리 회사에도 이런 것들이 있는데...기본적으로 기존 DB 저장 프로시저/T SQL을 통해 수행하기에는 너무 어렵거나 불가능했던 SQL 데이터에 대한 처리/논리 블록입니다.그래서 그들은 유사하게 호출할 수 있는 C++ DLL의 확장 저장 프로시저로 이를 작성했습니다.이제는 단계적으로 폐지되었으며 CLR 통합이 대체품입니다.

DB 저장 프로시저:T SQL Stored procs에서 수행할 수 있으면 수행하십시오.
CLR 저장 프로시저:논리가 T SQL을 통해 수행하기에는 너무 복잡하거나 지루한 경우...문자열 조작, 복합/사용자 지정 정렬 또는 필터링 등을 해결하기 위해 더 적은 줄의 CLR 코드가 필요한 경우 이 접근 방식을 사용하세요.

파일 시스템 액세스(CLR procs가 매우 뚜렷한 이점이 있는 경우)를 제외하고 저는 T-SQL procs를 사용합니다.특히 복잡한 계산이 있는 경우 해당 부분을 CLR에 넣을 수 있습니다. 기능 그리고 이를 proc 내에서 호출합니다(udf는 CLR 통합이 정말 빛을 발하는 곳입니다).그러면 작업의 특정 부분에 대해 CLR 통합의 이점을 얻을 수 있지만 저장된 프로세스 논리를 가능한 한 많이 DB에 유지합니다.

당신이 말한 내용을 고려할 때 개발자가 CLR에서 t-sql 작업을 수행하도록 허용하여 성능에 훨씬 더 많은 손상을 입히는 것보다 일반적으로 t-SQl 및 데이터베이스에 대해 적절한 교육을 받는 것이 좋습니다.데이터베이스를 이해하지 못하는 개발자는 더 쉬운 경로라고 생각하는 것을 선택하기 때문에 데이터베이스 성능에 가장 적합한 방식으로 작업을 수행하는 것을 피하려는 핑계로 이를 사용합니다.

이는 항상 작업에 적합한 도구로 귀결되므로 실제로 달성하려는 작업에 따라 달라집니다.

그러나 일반적으로 CLR 프로세스는 오버헤드가 더 크고 T-SQL과 같은 집합 작업을 수행하지 않는다는 것이 맞습니다.내 지침은 필요한 것이 T-SQL에서 지나치게 복잡해지지 않는 한 모든 작업을 T-SQL에서 수행하는 것입니다.그런 다음 T-SQL 접근 방식이 작동하도록 더 열심히 노력하십시오.:-)

CLR proc은 훌륭하고 그 자리를 차지하지만 예외적으로 사용해야 하며 규칙은 아닙니다.

SQL Server 온라인 설명서 해당 주제의 페이지 다음과 같은 이점을 나열합니다.

더 나은 프로그래밍 모델. .NET Framework 언어는 여러 측면에서 Transact-SQL보다 풍부하며 이전에는 SQL Server 개발자가 사용할 수 없었던 구문과 기능을 제공합니다.개발자는 프로그래밍 문제를 빠르고 효율적으로 해결하는 데 사용할 수 있는 광범위한 클래스 집합을 제공하는 .NET Framework 라이브러리의 기능을 활용할 수도 있습니다.
안전성과 보안이 향상되었습니다. 관리 코드는 데이터베이스 엔진이 호스팅하는 공용 언어 런타임 환경에서 실행됩니다.SQL Server는 이를 활용하여 이전 버전의 SQL Server에서 사용할 수 있는 확장 저장 프로시저에 대한 보다 안전하고 안전한 대안을 제공합니다.
데이터 유형 및 집계 함수를 정의하는 기능. 사용자 정의 유형과 사용자 정의 집계는 SQL Server의 저장소 및 쿼리 기능을 확장하는 두 가지 새로운 관리형 데이터베이스 개체입니다.
표준화된 환경을 통해 개발을 간소화합니다. 데이터베이스 개발은 Microsoft Visual Studio .NET 개발 환경의 향후 릴리스에 통합되었습니다.개발자는 중간 계층 또는 클라이언트 계층 .NET Framework 구성 요소 및 서비스를 작성하는 데 사용하는 것과 동일한 도구를 사용하여 데이터베이스 개체 및 스크립트를 개발하고 디버깅합니다.
성능과 확장성이 향상될 가능성이 있습니다. 많은 상황에서 .NET Framework 언어 컴파일 및 실행 모델은 Transact-SQL에 비해 향상된 성능을 제공합니다.

일반 SQL proc에서 수천 번 호출되는 CLR 함수와 관련된 상황이 발생했습니다.이는 다른 시스템에서 데이터를 가져오기 위한 프로세스였습니다.이 함수는 데이터의 유효성을 검사하고 null을 훌륭하게 처리했습니다.

TSQL에서 작업을 수행한 경우 프로세스는 약 15초 안에 완료되었습니다.CLR 기능을 사용한 경우 프로세스는 20~40분 안에 완료되었습니다.CLR 기능은 더 우아해 보였지만 우리가 아는 한 CLR 기능을 사용할 때마다 시작 히트가 있었습니다.따라서 하나의 CLR 함수를 사용하여 대규모 작업을 수행하는 경우 작업 시간에 비해 시작 시간이 짧으므로 괜찮습니다.또는 CLR 함수를 적당한 횟수만큼 호출하는 경우 모든 함수 호출에 대한 총 시작 시간은 짧습니다.하지만 루프에 주의하세요.

또한 유지 관리를 위해 실제로 필요한 것보다 더 많은 언어를 사용하지 않는 것이 더 좋습니다.

언급되지 않은 CLR을 사용해야 하는 몇 가지 이유를 추가하겠습니다.

기본 쿼리, 비쿼리, 스칼라 SQL 함수를 대체하고 확장합니다.
A) 오류 보고 및 경고는 정의된 요구 사항에 따라 통합될 수 있습니다.B) 디버깅 수준을 쉽게 정의합니다.C) 외부 SQL 서버와 더 쉽게 상호 작용할 수 있는 방법을 활성화합니다.
레거시 코드를 관리형 환경으로 이동합니다.

비슷한 질문에 다음 답변을 게시했습니다. SQL SERVER CLR의 장점.하지만 C#/VB.net/등은 T-SQL보다 누군가가 더 편한 언어라는 점을 여기에 추가하겠습니다. ~ 아니다 T-SQL보다 SQLCLR을 사용하는 이유가 됩니다.T-SQL로 작업을 수행하는 방법을 모르는 경우 먼저 T-SQL 솔루션을 찾는 데 도움을 요청하세요.존재하지 않는 경우, 그 다음에 CLR 경로로 이동합니다.

SQL Server 내의 SQLCLR/CLR 통합은 특정(전체는 아님) 문제를 해결하는 데 도움이 되는 또 다른 도구일 뿐입니다.순수 T-SQL에서 수행할 수 있는 것보다 더 나은 성능을 발휘하는 몇 가지 작업이 있으며, SQLCLR을 통해서만 수행할 수 있는 작업도 있습니다.저는 SQL Server Central에 대한 기사를 썼습니다. SQLCLR 수준 1의 계단:SQLCLR이란 무엇입니까? (기사를 읽으려면 무료 등록이 필요합니다), 이 질문을 해결합니다.기본 사항은 다음과 같습니다(자세한 내용은 링크된 문서 참조).

스트리밍 테이블 값 함수(sTVF)
동적 SQL(함수 내)
외부 리소스에 대한 액세스 향상 / xp_cmdshell 교체
- 데이터 전달이 더 쉬워졌습니다.
- 결과 세트의 여러 열을 다시 가져오는 것이 더 쉽습니다.
- 외부 종속성 없음(예:7zip.exe)
- 가장을 통한 보안 강화
멀티스레드 능력
오류 처리(함수 내)
사용자 정의 집계
사용자 정의 유형
상태 수정(함수 내에서 및 없이 OPENQUERY / OPENROWSET)
저장 프로시저 실행(읽기 전용,함수 내에서 그리고 함수 없이 OPENQUERY / OPENROWSET)
성능 (메모: 이것은 ~ 아니다 모든 경우에 의미가 있지만 일부 경우에는 작업의 유형과 복잡성에 따라 다릅니다)
출력을 캡처할 수 있습니다(예:SSMS의 메시지 탭으로 전송되는 내용)(예: PRINT 그리고 RAISERROR 와 심각성 = 0 ~ 10) -- 기사에서 이 내용을 언급하는 것을 잊어버렸습니다 ;-).

고려해야 할 또 다른 사항은 때로는 해당 앱 코드에 액세스하기 위해 사용자 정의 내부 전용 화면을 구축할 필요 없이 DB가 특정 비즈니스 로직에 대한 통찰력을 가질 수 있도록 앱과 DB 간에 코드를 공유할 수 있는 것이 유익할 수 있다는 것입니다.예를 들어, 저는 고객으로부터 데이터 파일을 가져오고 대부분의 필드에 대한 사용자 정의 해시를 사용하고 해당 값을 DB의 행에 저장하는 시스템에서 작업했습니다.이를 통해 앱이 입력 파일의 값을 해시하고 행에 저장된 해시 값과 비교하므로 데이터를 다시 가져올 때 쉽게 행을 건너뛸 수 있었습니다.동일하다면 필드가 변경되지 않았음을 즉시 알았으므로 다음 행으로 이동했으며 이는 간단한 INT 비교였습니다.그러나 해시를 수행하기 위한 알고리즘은 앱 코드에만 있으므로 고객 사례를 디버깅하거나 변경 사항이 있는 필드가 하나 이상 있는 행에 플래그를 지정하여 일부 처리를 백엔드 서비스로 오프로드하는 방법을 찾고 있는지 여부(앱에서 발생하는 변경 사항) 최신 가져오기 파일 내에서 변경 사항을 찾는 것과는 달리 제가 할 수 있는 일은 아무것도 없었습니다.이는 정상적인 처리가 아니더라도 DB에 다소 간단한 비즈니스 로직을 가질 수 있는 좋은 기회였을 것입니다.그 의미를 이해할 수 없는 상태에서 DB에 인코딩된 값이 있으면 문제를 해결하기가 훨씬 어렵습니다.

코드를 작성하지 않고도 이러한 기능 중 일부가 실제로 작동하는 모습을 보고 싶다면 다음의 무료 버전을 이용하세요. SQL# (내가 저자임)에는 RegEx 함수, 사용자 정의 집계(UDA), 사용자 정의 유형(UDT) 등이 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow