Pytanie, jak zauważył Remus, jest zbyt ogólne, aby uzyskać odpowiedź, ponieważ odpowiedź zależy od kontekstu, jaka funkcjonalność ma zostać użyta i jak zostanie wykorzystana.
W odniesieniu do „bezpieczeństwa”:
Jeśli pytasz o cokolwiek, co można zrobić w zestawie oznaczonym PERMISSION_SET = SAFE, oznacza to, że nie ma żadnych problemów, które kiedykolwiek mogłem znaleźć. A SQLCLR jest „bezpieczniejszy” niż używanie xp_cmdshelllub wspaniałe (to był sarkazm) sp_OA*procy (lub nawet Rozszerzone Procedury Przechowywane, ale mam nadzieję, że nikt już ich nie tworzy).
Jeśli chcesz dowiedzieć się, co oznacza „SAFE” w praktyce, zapoznaj się z tym artykułem: Schody do SQLCLR Poziom 3: Bezpieczeństwo (zespoły ogólne i SAFE) (wymagana bezpłatna rejestracja).
Jeśli pytasz o cokolwiek, co można zrobić w zestawie oznaczonym PERMISSION_SET = EXTERNAL_ACCESS, to z pewnością istnieje ryzyko, ponownie, w zależności od używanej funkcjonalności. Jeśli piszesz procedurę czytania katalogów i nazw plików (tj. Tylko do odczytu), to tylko kwestia tego, co powinno być widoczne, a czego nie. Jeśli piszesz kod, który pozwala na usunięcie pliku, ryzyko wzrasta. Ale to, co można zrobić z tymi zasobami zewnętrznymi, jest kontrolowane przez:
- niezależnie od tego, czy używasz Podszywania się:
- brak personifikacji oznacza, że dostęp do zasobów zewnętrznych odbywa się za pośrednictwem konta „Zaloguj się jako” usługi SQL Server. Bez względu na to, do czego konto ma dostęp, funkcja SQLCLR będzie w stanie to zrobić.
- użycie Personifikacji oznacza, że Logowanie w SQL Server, który uruchamia tę funkcję, jeśli to logowanie odpowiada loginowi Windows, może robić wszystko, co jest dozwolone. Jeśli login w SQL Server to login SQL Server, wówczas próba użycia personifikacji spowoduje błąd.
- Jakie uprawnienia są skonfigurowane dla zasobu zewnętrznego. W przypadku dostępu do systemu plików jest to kontrolowane przez listy ACL na dyskach NTFS.
Jeśli pytasz o cokolwiek, co można zrobić w zestawie oznaczonym PERMISSION_SET = UNSAFE, to jest dość otwarte. Wiele funkcji uważa się za użyteczne tylko w zespołach UNSAFE, ponieważ są to kwestie stabilności i / lub spójnego zachowania bardziej niż bezpieczeństwo lub wydajność. Na przykład w zespole UNSAFE można mieć zapisywalną zmienną statyczną. Zazwyczaj nie jest to dobre, ponieważ klasy SQLCLR są wspólne dla wszystkich sesji. Jeśli masz zamiar udostępniać dane w pamięci we wszystkich sesjach i zaplanowałeś warunki wyścigu (i wykonałeś wiele testów), powinieneś być w porządku, ponieważ spodziewasz się takiego zachowania. Ale jeśli po prostu chciałeś, aby zapisywalna zmienna statyczna buforowała wartość dla konkretnej sesji, aby nie musieć jej ponownie sprawdzać ani obliczać, i nie byłaś świadoma tego, że inne sesje odczytują tę wartość i prawdopodobnie ją nadpisują, cóż, to byłby problem.
Ale jeśli martwisz się o kogoś, kto pisze do Rejestru, ale nie masz żadnego kodu, który faktycznie zapisuje w Rejestrze, prawdopodobnie nie musisz się tym martwić ;-).
Jeśli chcesz zapoznać się z praktycznym działaniem EXTERNAL_ACCESS i UNSAFE oraz różnicą między ustawieniem TRUSTWORTHY ON(nie preferowanym) a użyciem Asymetrycznego logowania opartego na kluczu lub certyfikacie, zapoznaj się z tym artykułem: Schody do SQLCLR poziom 4: Bezpieczeństwo (zespoły ZEWNĘTRZNE i NIEBEZPIECZNE) (wymagana bezpłatna rejestracja).
W odniesieniu do „wydajności”:
To wszystko zależy od tego, co próbujesz zrobić i jak to zrobić. Istnieją pewne rzeczy, które są znacznie szybsze w SQLCLR, a niektóre rzeczy, które są wolniejsze. Ale podobnie jak w przypadku T-SQL, możliwe jest podjęcie nieco prostego i / lub wydajnego zadania oraz uczynienie go skomplikowanym i / lub nieefektywnym poprzez nieprawidłowe działanie. Ale korzystanie z SQL CLR nie jest z natury z natury wolniejsze.