다른 데이터베이스의 내부 저장 프로 시저에 사용할 중앙 CLR 저장 프로 시저 / 함수 저장소 라이브러리를 설정 하시겠습니까?

C # CLR에서 개발 한 코드를 사용하여 시스템의 모든 데이터베이스에서 사용할 수 있도록 각 코드를 신뢰할 수 있고 CLR을 켜고 각 코드 안에 동일한 코드를 유지하지 않아도됩니다. .

관리 및 보안 관점에서이 작업을 수행하는 가장 좋은 방법이 있습니까? CLR 함수는 문자열 차단기, 전자 메일 유효성 검사, url en / decode, base64 등과 같이 매우 기본적입니다. 각 데이터베이스의 dbo 스키마 만 함수에 액세스 할 수 있기를 바랍니다.

1. 이 작업을 수행하는 간단한 방법이 있습니까?
2. 또한 CLR dll이 포함되어 있고 데이터베이스를 이동하면 태그가 지정되거나 dll도 이동 해야하는지 확실하지 않습니다.

감사

우리 회사에는 정확한 설정이 있습니다. CLR 어셈블리를 만들면 어셈블리의 이진 표현이 사용자가 만든 데이터베이스 내에 저장됩니다. 이렇게하면 언제든지 데이터베이스를 이동할 때 가져 와서 스크립트를 작성할 수 있습니다.

몇 달 전에 데이터 센터가 침수되어 여러 서버에 물이 가득 차있었습니다. 내가 그들을 재건 할 때 나는 전날 밤에 찍은 db의 백업 만 사용했습니다. 지금까지 우리는 문제가 없었습니다 .. (터치 우드!)

이것이 보안 관점에서 올바른 일인지 확실하지 않지만 CLR 프로세스 등에 대한 액세스 권한을 부여하는 방법은 공유 데이터베이스 내에 역할을 만든 다음 다른 데이터베이스의 사용자를 해당 역할에 추가하는 것입니다. 그런 다음 CLR 프로세스에서 역할이 실행됩니다.

CLR이 포함 된 데이터베이스 외부의 리소스에 대한 액세스와 같은 작업을 수행하려고하지만 어셈블리를 만들 때 어셈블리에 대한 권한을 설정할 수있는 경우 액세스 문제가있을 수 있습니다. 아래 링크에는 여기에 설명 할 수있는 것보다 권한에 관한 많은 정보가 있습니다.

http://msdn.microsoft.com/en-us/library/ms345101.aspx

이것이 도움이되기를 바랍니다.

어셈블리 바이너리는 데이터베이스에 Blob으로 저장되므로 데이터베이스가있는 곳마다 전달됩니다. CLR은 인스턴스 에서만 활성화되며 데이터베이스 별 설정이 없습니다.

어쨌든 왜 이것을하려고합니까?

(나는 논증하려고하지 않습니다. 문제가 당신의 요구를 충족시키는 다른 방법으로 해결 될 수 있기 때문에 관련된 동기를 듣고 싶습니다.)

어셈블리를 공유 데이터베이스에 넣는 것 외에는이 작업을 쉽게 수행 할 수있는 방법이 없습니다.

즉, 중앙 집중화해야 할 특별한 이유가없는 한 데이터베이스 중심 아키텍처를 수용하는 것이 유리하다고 생각합니다. 그 이유는 데이터베이스 외부에 어셈블리 (또는 그 문제에 대한 것)를두면 환경에 의존성이 생기기 때문입니다. 이는 Microsoft가 SQL Server 2012부터 포함 된 데이터베이스를 사용하여 구축하는 것과 정반대의 접근 방식입니다.

• 복제 또는 클러스터링과 같은 기능을 사용하기 시작하면 이러한 종속성으로 인해 배포가 상당히 복잡해 지지만 문제 해결 및 장애 조치 절차가 복잡해질 수 있습니다.

• 이 아키텍처는 시스템에 익숙하지 않은 사람들에게는 훨씬 덜 명확합니다 (즉, 자체 발견이 적고 자체 문서화가 적음).

• 다른 데이터베이스 또는 변형이 포함 된 모든 항목에서 서로 다른 보안이 필요한 경우 상처를 입을 수 있습니다.

• 이러한 데이터베이스가 고객에게 배포되면 (그렇지 않은 것처럼 들리지만 완벽하다고 말할 수 있음) 배포 절차, 유지 관리 및 문제 해결이 복잡해집니다.

• 모든 데이터베이스가이 코드를 공유하므로 버그가 발생하거나 수정 된 경우 데이터베이스에 의존하는 모든 응용 프로그램이 손상 될 수 있습니다. 포괄적 인 단위 테스트는 반드시 필요합니다.

동일한 기능을 필요로하는 데이터베이스가 여러 개인 경우, 관련된 중복의 양을 줄이는 다른 방법이 있습니다. 연습의 핵심이라고 생각합니다. 상당히 복잡한 CLR 어셈블리조차도 데이터베이스 자체의 데이터 (거의 항상)와 비교하여 많은 물리적 스토리지 공간을 차지하지 않으므로 문자 그대로 수천 개의 작은 데이터베이스가없는 한 유효한 인수로 보지 못합니다. 어셈블리.

수행 할 수있는 작업은 소스 복제를 줄이기 위해 이러한 데이터베이스에 대한 배포 절차의 다른 부분을 수정하는 것입니다. 예를 들어, 소스 제어에서 CLR 코드의 공통 위치에서 어셈블리를 빌드하고 배치하십시오. 또는 동일한 어셈블리를 데이터베이스에 배포하는 스크립트를 작성하십시오. 이 부분을 가능한 한 많이 자동화하면 큰 문제가되지 않습니다.

필자가 제안한 것은 여전히 ​​중복이있을 것이기 때문에 트레이드 오프라는 데 동의하지만 규정 된 표준을 따르지 않는 아키텍처 구현과 관련된 단점과 균형을 이루어야합니다. 오직 당신 만이 당신의 환경에 맞는 것을 결정할 수 있습니다.

다른 두 가지 답변의 상태가 정확하기 때문에 어셈블리는 특정 데이터베이스에로드되고 시스템 전체는 아닙니다 ( assembly_id값 이 시스템 전체에서 고유 하다는 것이 확실합니다 ). 이는 이들이로드 된 각 데이터베이스와 함께 백업 및 복원됨을 의미합니다.

또한, enabled/ 용 disabled의 설정 CLR Integration(비아 sp_configure) 인 시스템 전체. 참고로이 설정은 사용자가 만든 CLR 기능 에만 적용 됩니다. 특정 내장 기능에 따라 CLR이 항상 사용됩니다.

즉, 여기에있는 다른 두 가지 대답은 유효한 점을 제시하지만 그 점은 SQLCLR에 국한되지 않으며 SQLCLR 코드와 관련된이 결정을 내리는 요인에 대한 언급은 없습니다. 각 데이터베이스에 코드를 배포 할 경우 (데이터베이스가 많다고 가정 할 때) 잠재적 인 리소스 경합 문제, 잠재적 보안 관련 문제 등을 고려해야 할 메모리 문제가 있습니다.

중앙 데이터베이스와 개별 데이터베이스 배포 사이를 결정할 때 특히 SQLCLR 코드에 대해 명심해야 할 포괄적 인 목록을 제공했습니다. 여기에 목록을 복제하지 말고 다음 답변을 참조하십시오 (DBA.SE에도 있습니다).

성능 관점에서 CLR 기능을 더 잘 사용하는 방법 (각 DB 내부에서 반복하거나 일반 기능이 있음)?

또한 관련 메모에서 데이터베이스가 왜 설정되어 있는지 궁금합니다 TRUSTWORTHY ON. 질문에 언급 된 기능 (예 : "문자열 차단기, 이메일 유효성 검사, URL 인코딩 /베이스 디코딩, base64 등")은 모두 SAFE어셈블리 내에서 가능합니다 . 꼭 필요한 경우가 아니면 EXTERNAL_ACCESS, UNSAFEperission_set 값을 사용해서는 안됩니다 . 이 기능의 일부 번호 필요한 경우, 그때 그에만 포함 된 별도의 조립에 있어야 SAFE코드를 같은 데이터 액세스를하지 않는 스칼라 함수 것을 하고 로 표시된는 IsDeterministic = true존재의 성능 이점을 활용할 수있을 것입니다 병렬 계획에 참여할 수 있습니다.