La domanda, come ha sottolineato Remus, è troppo generica per ottenere una risposta poiché la risposta dipende dal contesto di quale funzionalità deve essere utilizzata e come verrà utilizzata.
Per quanto riguarda "Sicurezza":
Se stai chiedendo qualcosa che può essere fatto in un assieme contrassegnato da PERMISSION_SET = SAFE, allora non ci sono problemi che io abbia mai potuto trovare. E SQLCLR è "più sicuro" dell'uso xp_cmdshello dei meravigliosi proc (che erano sarcasmi) sp_OA*(o anche delle Extended Stored Procedures, ma speriamo che nessuno ne stia creando più).
Se desideri una panoramica di cosa significhi "SICURO" in termini pratici, consulta questo articolo: Scala per SQLCLR Livello 3: Sicurezza (assemblee generali e SAFE) (è richiesta la registrazione gratuita).
Se stai chiedendo qualcosa che può essere fatto in un assieme contrassegnato da PERMISSION_SET = EXTERNAL_ACCESS, allora ci sono sicuramente dei rischi, a seconda di quale funzionalità viene utilizzata. Se scrivi una routine per leggere directory e nomi di file (cioè di sola lettura), allora è solo una questione di ciò che dovrebbe essere visto e non visto. Se si sta scrivendo un codice che consente di eliminare un file, il rischio aumenta. Ma cosa si può fare con quelle risorse esterne è controllato da:
- indipendentemente dal fatto che si stia utilizzando Impersonation:
- nessuna rappresentazione significa che l'accesso alle risorse esterne viene effettuato tramite l'account "Accedi come" del servizio SQL Server. Qualunque sia l'account a cui ha accesso, la tua funzione SQLCLR sarà in grado di fare.
- l'utilizzo di Rappresentazione significa che l'Accesso in SQL Server che esegue la funzione, se l'Accesso corrisponde a un Accesso Windows, può fare tutto ciò che quel particolare Accesso Windows è autorizzato a fare. Se il login in SQL Server è un login di SQL Server, il tentativo di utilizzare la rappresentazione avrà un errore.
- Quali autorizzazioni sono impostate sulla risorsa esterna. Per l'accesso al filesystem, questo è controllato tramite ACL su unità NTFS.
Se stai chiedendo qualcosa che può essere fatto in un assieme contrassegnato da PERMISSION_SET = UNSAFE, che è abbastanza aperto. Molte funzionalità sono considerate utilizzabili solo negli assiemi UNSAFE perché sono problemi di stabilità e / o comportamento coerente più che di sicurezza o prestazioni. Ad esempio, in un assembly UNSAFE è possibile avere una variabile statica scrivibile. Questo in genere non è una buona cosa da fare poiché le classi SQLCLR sono condivise in tutte le sessioni. Se la tua intenzione è quella di condividere i dati in memoria in tutte le sessioni e hai pianificato le condizioni di gara (e fatto molti test), allora dovresti stare bene perché ti aspetti questo comportamento. Ma se volevi semplicemente che una variabile statica scrivibile memorizzasse nella cache un valore per una determinata sessione in modo da non doverlo cercare di nuovo o calcolarlo di nuovo, e non eri consapevole che altre sessioni stanno leggendo quel valore e probabilmente sovrascrivendolo, beh, sarebbe un problema.
Ma se sei preoccupato per qualcuno che scrive nel Registro di sistema, ma non hai ancora alcun codice che scriva effettivamente nel Registro di sistema, probabilmente non devi preoccuparti di questo ;-).
Se desideri una panoramica di come EXTERNAL_ACCESS e UNSAFE funzionano in termini pratici e la differenza tra impostazione TRUSTWORTHY ON(non preferita) e utilizzo di un accesso asimmetrico basato su chiave o certificato, consulta questo articolo: Scala per SQLCLR Livello 4: Sicurezza (assemblee ESTERNE e UNSAFE) (è richiesta la registrazione gratuita).
Per quanto riguarda "Performance":
Questa è tutta una questione di ciò che stai cercando di fare e di come lo fai. Ci sono alcune cose che sono molto più veloci in SQLCLR e altre che sono più lente. Ma proprio come con T-SQL, è possibile svolgere un compito piuttosto semplice e / o efficiente e renderlo complicato e / o inefficiente facendo le cose in modo errato. Ma l'utilizzo di SQL CLR non è intrinsecamente, per sua stessa natura, più lento.