Remus'un da işaret ettiği gibi, cevap hangi işlevselliğin kullanılacağı ve nasıl kullanılacağı bağlamına bağlı olduğu için bir cevap alamayacak kadar geneldir.
"Güvenlik" ile ilgili:
İle işaretlenmiş bir montajda yapılabilecek herhangi bir şey soruyorsanız PERMISSION_SET = SAFE, bulabildiğim herhangi bir sorun yoktur. Ve SQLCLR kullanmaktan xp_cmdshellya da harika (iğneleyici) sp_OA*prokslardan (hatta Genişletilmiş Saklı Prosedürlerden daha "güvenlidir" ama umarım kimse bunlardan hiçbirini yaratmaz).
Pratik olarak "GÜVENLİ" ne anlama geldiğini görmek isterseniz, lütfen şu makaleye bakın: SQLCLR Merdiven Seviye 3: Güvenlik (Genel ve SAFE Meclisleri) (ücretsiz kayıt gereklidir).
İşaretli bir montajda yapılabilecek herhangi bir şey soruyorsanız PERMISSION_SET = EXTERNAL_ACCESS, hangi işlevin kullanıldığına bağlı olarak kesinlikle riskler vardır. Dizinleri ve dosya adlarını (yani salt okunur) okumak için bir rutin yazarsanız, bu sadece görülmesi ve görülmemesi gereken bir konudur. Bir dosyayı silmenize izin veren bir kod yazıyorsanız, risk artar. Ancak bu dış kaynaklarla neler yapılabilir :
- Kimliğe Bürünme özelliğini kullanıp kullanmadığınız:
- hiçbir Kimliğe Bürünme, dış kaynaklara erişimin SQL Server hizmetinin "Farklı oturum aç" hesabı aracılığıyla yapıldığı anlamına gelir. Bu hesabın erişimi ne olursa olsun, SQLCLR işleviniz bunu yapabilir.
- Kimliğe Bürünme işlevinin kullanılması, SQL Server'da Oturum Açma işlevinin çalıştığı anlamına gelir; bu Oturum Açma bir Windows Oturum Açma'ya karşılık geliyorsa, belirli Windows Oturum Açma işleminin yapmasına izin verilen her şeyi yapabilir. SQL Server'da Oturum Açma işlemi bir SQL Server Oturum Açma İşlemi ise, Kimliğe Bürünme özelliğini kullanmaya çalışmak bir hata alır.
- Harici kaynakta hangi izinler ayarlanır. Dosya sistemi erişimi için bu, NTFS sürücülerindeki ACL'ler aracılığıyla denetlenir.
İle işaretlenmiş bir montajda yapılabilecek herhangi bir şey soruyorsanız PERMISSION_SET = UNSAFE, bu oldukça açık uçlu. Güvenlik veya performanstan daha fazla istikrar ve / veya tutarlı davranış sorunları olduğundan, birçok işlevsellik yalnızca UNSAFE meclislerinde kullanılabilir olarak kabul edilir. Örneğin, UNSAFE montajında yazılabilir bir statik değişken olması mümkündür. SQLCLR sınıfları tüm oturumlarda paylaşıldığından, bu genellikle iyi bir şey değildir. Amacınız verileri tüm oturumlarda bellekte paylaşmak ve yarış koşullarını (ve bol miktarda test yapmayı) planlamaksa, bu davranışı beklediğiniz için iyi olmalısınız. Ancak, yazılabilir bir statik değişkenin, belirli bir oturum için bir değeri tekrar aramak veya tekrar hesaplamak zorunda kalmaması için önbelleğe almasını istiyorsanız ve diğer oturumların bu değeri okuduğunu ve muhtemelen üzerine yazdığını bilmiyorsanız, bu bir sorun olurdu.
Ancak birisinin Kayıt Defterine yazmasından endişe ediyorsanız, ancak aslında Kayıt Defterine yazan herhangi bir kodunuz yoksa, muhtemelen bu ;-) için endişelenmenize gerek yoktur.
EXTERNAL_ACCESS ve UNSAFE'nin pratikte nasıl çalıştığına ve TRUSTWORTHY ONAsimetrik Anahtar veya Sertifika Tabanlı Giriş kullanma ile ayar (tercih edilmeyen) ile fark arasındaki farka bakmak isterseniz , lütfen bu makaleye bakın: SQLCLR Seviye 4 Merdivenleri: Güvenlik (HARİCİ ve UNSAFE Meclisleri) (ücretsiz kayıt gereklidir).
"Performans" ile ilgili:
Tüm bunlar ne yapmaya çalıştığınız ve bunu yapmaya nasıl devam ettiğinizle ilgilidir. Bazı şeyler vardır çok daha hızlı SQLCLR içinde ve yavaş bazı şeyler. Ancak T-SQL'de olduğu gibi, biraz basit ve / veya verimli bir görev almak ve işleri yanlış yaparak karmaşık ve / veya verimsiz hale getirmek mümkündür. Ancak SQL CLR'yi kullanmak doğası gereği daha yavaş değildir.