Comparação das extensões de linguagem do SQL Server com o SQL CLR
Aplica-se a: 
SQL Server 2019 (15.x) e versões posteriores
Este artigo compara as Extensões de Linguagem do SQL Server e o CLR (common language runtime) nativo. Ele identifica as principais diferenças entre elas e ajuda você a decidir qual usar.
As Extensões de Linguagem do SQL Server são um recurso do SQL Server usado para executar código externo. Os dados relacionais podem ser usados no código externo usando a estrutura de extensibilidade.
O CRL (Common Language Runtime) nativo permite que você implemente algumas das funcionalidades do SQL Server com linguagens .NET. O CLR fornece código gerenciado com serviços como integração entre idiomas, segurança de acesso do código, gerenciamento do tempo de vida de objetos e suporte à depuração e à criação de perfis.
As linguagens disponíveis nas Extensões de Linguagem do SQL Server não são uma substituição direta do SQL CLR. A estrutura de extensibilidade e as extensões de linguagem estendem a área de superfície do SQL Server e fornecem um ambiente de execução para runtimes mais próximos do mecanismo de banco de dados. Eles também fornecem uma estrutura de código aberto que pode ser usada para integrar novos tempos de execução sem alterações no mecanismo. Atualmente, a área de superfície está restrita ao procedimento armazenado do sistema, sp_execute_external_script.
Veja abaixo algumas das principais diferenças entre as extensões de linguagem SQL e SQL CLR:
| Recurso | SQL CLR | Extensões de linguagem do SQL |
|---|---|---|
| Suporte a plataforma | Windows e Linux – o Linux oferece suporte somente a assemblies SAFE. |
Windows e Linux – paridade total em termos de funcionalidade. |
| Modo de execução | Em processo | Fora de processo |
| Isolamento | O código CLR é executado dentro do processo do mecanismo. O administrador da instância precisa confiar em todos os assemblies/códigos. | A execução de runtime ocorre fora do processo do mecanismo. Mais isolamento é fornecido usando Contêineres de Aplicativo no Windows ou Namespaces no Linux. A comunicação de rede externa também é desabilitada por padrão. |
| Sintaxe declarativa (T-SQL) | Tipos e agregações definidos pelo usuário e funções, procedimentos e gatilhos. | Somente execução ad hoc usando o sp_execute_external_script. |
| Suporte para DDL | CREATE ASSEMBLY para carregar o código do usuário e definir outros objetos (funções, processos, gatilhos UDTs, UDAggs). |
CREATE EXTERNAL LANGUAGE, EXTERNAL LIBRARY para gerenciar extensões e bibliotecas. |
| Suporte à biblioteca | Obtido por meio de assemblies. | Bibliotecas para runtime específico podem ser usadas (por exemplo: pacotes R ou Python, bibliotecas Java). |
| Runtimes com suporte | .NET Framework | R, Python, Java, C# ou Traga seu Próprio Runtime (BYOR). |
| Estrutura de OSS | N/D – pode ser estendido por meio de assemblies .NET definidos pelo usuário. | Sim – a extensão SDK fornece a criação de novas extensões ou integração com runtimes sem alterações no mecanismo. |
| Integração com QO | Integração no nível de operador para várias sintaxes, incluindo paralelismo. | Operador de script externo único para enviar/receber resultados e dados de runtime, esse operador dá suporte à execução em modo de lote e paralelismo. |
| Governança de recursos | Nenhum – poucos botões fora do administrador de recursos. | Fornece o objeto EXTERNAL RESOURCE POOL como um mecanismo separado para controlar os recursos consumidos pelos scripts de runtime/externos. Além da carga de trabalho de SQL, as políticas podem ser definidas para runtimes externos. |
| Modelo de permissão | Controle de nível de instância com objetos no escopo do BD. | Controle de nível de instância com objetos no escopo do BD. |
| Desempenho | O código SQL CLR normalmente excede a extensibilidade devido à natureza da execução. | Ideal para execução orientada por lote. |
| Monitoramento de recursos | sys.dm_clr* DMVs e contador de monitoramento de desempenho específico do SQL CLR limitado. |
sys.dm_external* DMVs, DMVs do pool de recursos externos, contadores de monitoramento de desempenho de JobObject do Windows. |
Quando usar cada um deles
O uso de Extensões de Linguagem ou CLR depende de seus cenários e objetivos. Por exemplo, se você precisar estender a área de superfície de T-SQL com suas próprias agregações ou tipos, o CLR será a melhor opção, já que não é possível definir o tipo ou a agregação usando o mecanismo de extensibilidade. Por outro lado, se você quiser usar a experiência de ciência de dados existente em sua organização ou equipe, usar a integração de R/Python com extensibilidade é a melhor opção.
Da mesma forma, suas metas de desempenho podem determinar sua decisão. Implementar uma função regex em C# e usar CLR é muito mais rápido do que usar a extensibilidade para invocar um script Python que executa a mesma funcionalidade regex.