Remus가 지적했듯이 질문은 답변이 사용되는 기능의 컨텍스트와 사용 방법에 따라 달라지기 때문에 답변을 얻기에는 너무 일반적입니다.
"보안"에 관하여 :
로 표시된 어셈블리에서 수행 할 수있는 작업에 대해 질문하는 경우 PERMISSION_SET = SAFE내가 찾은 문제가 없습니다. 그리고 SQLCLR은 사용 xp_cmdshell하거나 멋진 (비꼬 인) sp_OA*procs (혹은 확장 저장 프로 시저 (Extended Stored Procedures ))를 사용 하는 것보다 "더 안전하다" .
"SAFE"가 실제로 의미하는 바를 살펴 보려면 SQLCLR 계단 3 : 보안 (일반 및 SAFE 어셈블리)의 계단 (무료 등록 필요) 문서를 참조하십시오 .
로 표시된 어셈블리에서 수행 할 수있는 작업에 대해 묻는 경우 PERMISSION_SET = EXTERNAL_ACCESS사용중인 기능에 따라 다시 위험이 있습니다. 디렉토리와 파일 이름을 읽는 루틴을 작성하면 (즉, 읽기 전용),보아야 할 것과 보이지 않는 것의 문제 일뿐입니다. 파일을 삭제할 수있는 코드를 작성하면 위험이 증가합니다. 그러나 이러한 외부 리소스로 수행 할 수 있는 작업은 다음에 의해 제어됩니다.
- 가장을 사용하는지 여부 :
- 가장은 SQL Server 서비스의 "로그온 계정"계정을 통해 외부 리소스에 액세스하는 것을 의미합니다. 해당 계정이 액세스 할 수있는 모든 SQLCLR 기능이 가능합니다.
- 가장을 사용한다는 것은 해당 로그인이 Windows 로그인에 해당하는 경우 함수를 실행하는 SQL Server의 로그인이 특정 Windows 로그인이 허용하는 모든 작업을 수행 할 수 있음을 의미합니다. SQL Server의 로그인이 SQL Server 로그인 인 경우 가장을 사용하려고하면 오류가 발생합니다.
- 외부 리소스에 어떤 권한이 설정되어 있습니까? 파일 시스템 액세스의 경우 NTFS 드라이브의 ACL을 통해 제어됩니다.
로 표시된 어셈블리에서 수행 할 수있는 작업에 대해 질문하는 경우 PERMISSION_SET = UNSAFE, 그것은 상당히 개방적입니다. 많은 기능은 보안 또는 성능 이상의 안정성 및 / 또는 일관된 동작 문제이므로 UNSAFE 어셈블리에서만 사용할 수있는 것으로 간주됩니다. 예를 들어 UNSAFE 어셈블리에서 쓰기 가능한 정적 변수를 가질 수 있습니다. SQLCLR 클래스가 모든 세션에서 공유되므로 일반적으로이 방법은 좋지 않습니다. 모든 세션에서 메모리의 데이터를 공유하고 경쟁 조건을 계획하고 (많은 테스트를 수행하려는 경우)이 동작을 예상하는 것이 좋습니다. 그러나 단순히 특정 세션에 대한 값을 캐시하여 다시 조회하거나 다시 계산할 필요가없는 쓰기 가능한 정적 변수를 원했고 다른 세션이 해당 값을 읽고 덮어 쓸 수 있다는 것을 알지 못하는 경우, 그것은 문제가 될 것입니다.
그러나 누군가 레지스트리에 쓰는 것이 걱정되지만 실제로 레지스트리에 쓰는 코드가 없다면 걱정할 필요가 없습니다. ;-).
EXTERNAL_ACCESS 및 UNSAFE가 실제 용어로 작동하는 방식과 TRUSTWORTHY ON비대칭 키 또는 인증서 기반 로그인 사용과 설정 (권장하지 않음) 의 차이점을 살펴 보려면 SQLCLR 레벨 4의 계단을 참조하십시오 . 보안 (외부 및 UNSAFE 어셈블리) (무료 등록 필요).
"성능"에 관하여 :
이것은 모두 당신이하려는 일과 그것을하는 방법에 관한 문제입니다. 몇 가지 일들이 있습니다 훨씬 빠른 SQLCLR, 그리고 느린 몇 가지. 그러나 T-SQL과 마찬가지로 다소 간단하고 효율적인 작업을 수행하고 잘못 수행하여 복잡하고 비효율적으로 만들 수 있습니다. 그러나 SQL CLR을 사용하는 것이 본질적으로 느리지는 않습니다.