Por que não consigo usar variáveis ​​no T-SQL como imagino que posso?

Perdoe-me, sou um desenvolvedor que se mudou para o mundo do SQL. Eu pensei que poderia melhorar um pouco de SQL adicionando variáveis, mas não funcionou como eu esperava. Alguém pode me dizer por que isso não funciona? Não quero uma solução alternativa, quero saber as razões pelas quais isso não funciona como imagino que deva, pois tenho certeza de que há uma boa razão, mas, atualmente, não me ocorre.

DECLARE @DatabaseName varchar(150)
SET @DatabaseName = 'MyAmazingDatabaseName'

CREATE DATABASE @DatabaseName
GO

USE @DatabaseName
GO

De acordo com a página online do Books para variáveis

As variáveis ​​podem ser usadas apenas em expressões, não no lugar de nomes de objetos ou palavras-chave. Para construir instruções SQL dinâmicas, use EXECUTE.

Funcionaria da maneira que você esperava se, por exemplo, você usasse sua variável em uma cláusula where. Quanto ao porquê, eu acho que tem algo a ver com o analisador que não é capaz de avaliar a variável e, assim, verificar a existência. Ao executar, a consulta é analisada primeiro para sintaxe e objetos e, em seguida, se a análise for bem-sucedida, a consulta é executada no ponto em que a variável seria definida.

DECLARE @name varchar(20);
SET @name = 'test';

CREATE TABLE [#tmp]([val] varchar(10));

insert into #tmp
values('test')

SELECT *
FROM [#tmp]
WHERE [val] = @name;

As limitações no uso de variáveis ​​nas instruções SQL surgem da arquitetura do SQL.

Existem três fases no processamento de uma instrução SQL:

1. Preparação - A instrução é analisada e um plano de execução é compilado, especificando quais objetos de banco de dados são acessados, como são acessados ​​e como estão relacionados. O plano de execução é salvo no cache do plano .
2. Ligação - todas as variáveis ​​na instrução são substituídas pelos valores reais.
3. Execução - o plano em cache é executado com os valores associados.

O servidor SQL oculta a etapa de preparação do programador e a executa muito mais rapidamente do que os bancos de dados mais tradicionais, como Oracle e DB2. É por razões de desempenho que o SQL gasta potencialmente muito tempo determinando um plano de execução ideal, mas somente na primeira vez que a instrução é encontrada após uma reinicialização.

Portanto, no SQL estático , as variáveis ​​podem ser usadas apenas em locais onde não invalidarão o plano de execução, portanto, não para nomes de tabelas, nomes de colunas (incluindo nomes de colunas nas condições WHERE), etc.

O SQL dinâmico existe para os casos em que não é possível contornar as restrições, e o programador sabe que levará um pouco mais de tempo para executar. O SQL dinâmico pode ser vulnerável à injeção de código malicioso, portanto, tome cuidado!

Como você pode ver, a pergunta "por que" requer um tipo diferente de resposta, incluindo a justificativa histórica e as suposições subjacentes ao idioma, não tenho certeza de que possa realmente fazer essa justiça.

Este artigo abrangente do MVP do SQL Erland Sommarskog tenta fornecer algumas justificativas, junto com a mecânica:

A maldição e as bênçãos do SQL dinâmico :

Cache de planos de consulta

Toda consulta que você executa no SQL Server requer um plano de consulta. Quando você executa uma consulta pela primeira vez, o SQL Server cria um plano de consulta para ela - ou conforme a terminologia - compila a consulta. O SQL Server salva o plano no cache e, da próxima vez que você executar a consulta, o plano será reutilizado.

Este (e segurança, veja abaixo) é provavelmente o maior motivo.

O SQL opera sob a premissa de que as consultas não são operações únicas, mas que serão usadas repetidamente. Se a tabela (ou o banco de dados!) Não estiver realmente especificada na consulta, ela não poderá gerar e salvar um plano de execução para uso futuro.

Sim, nem todas as consultas que executamos serão reutilizadas, mas essa é a premissa operacional padrão do SQL , portanto, as "exceções" devem ser excepcionais.

Algumas outras razões pelas quais Erland lista (observe que ele lista explicitamente as vantagens de usar procedimentos armazenados , mas muitos deles também são vantagens de consultas parametrizadas (não dinâmicas)):

• O sistema de permissão : o mecanismo SQL não pode prever se você tem o direito de executar uma consulta se não souber a tabela (ou banco de dados) em que estará operando. "Cadeias de permissão" usando SQL dinâmico é um problema.
• Reduzindo o tráfego de rede : passar o nome do processo armazenado e alguns valores de parâmetro na rede é mais curto que uma declaração de consulta longa.
• Lógica de encapsulamento : você deve estar familiarizado com as vantagens de encapsular a lógica de outros ambientes de programação.
• Acompanhar o que é usado : Se eu precisar alterar uma definição de coluna, como posso encontrar todo o código que a chama? Os procedimentos do sistema existem para localizar dependências em um banco de dados SQL, mas apenas se o código estiver em procedimentos armazenados.
• Facilidade de escrever código SQL : a verificação de sintaxe ocorre quando você cria ou modifica um procedimento armazenado, resultando em menos erros.
• Resolvendo Bugs e Problemas : Um DBA pode rastrear e medir o desempenho de procedimentos armazenados individuais com muito mais facilidade do que o SQL dinâmico em constante mudança.

Novamente, cada uma delas tem uma centena de nuances nas quais não vou entrar aqui.

Você precisa usar sql dinâmico

DECLARE @DatabaseName varchar(150) = 'dbamaint'
declare @sqltext nvarchar(max) = N''

set @sqltext = N'CREATE DATABASE '+quotename(@DatabaseName)+ ';'

print @sqltext 

-- once you are happy .. uncomment below
--exec sp_executesql @sqltext
set @sqltext = ''
set @sqltext = N'use '+quotename(@DatabaseName)+ ';'
print @sqltext 
-- once you are happy .. uncomment below
--exec sp_executesql @sqltext

abaixo está o resultado da impressão .. depois de descomentar, exec sp_executesql @sqltextas instruções serão realmente executadas ...

CREATE DATABASE [dbamaint];
use [dbamaint];