Perché non posso usare le variabili in T-SQL come immagino di poter?

Perdonami, sono uno sviluppatore che si è trasferito nel mondo di SQL. Pensavo di poter migliorare alcuni SQL aggiungendo variabili ma non funzionava come mi aspettavo. Qualcuno può dirmi perché questo non funziona? Non voglio lavorare in giro, voglio sapere i motivi per cui questo non funziona come immagino che dovrebbe, dato che sono sicuro che ci sia una buona ragione, ma attualmente non mi salta addosso.

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

CREATE DATABASE @DatabaseName
GO

USE @DatabaseName
GO

Per la pagina online di Libri per le variabili

Le variabili possono essere utilizzate solo nelle espressioni, non al posto di nomi di oggetti o parole chiave. Per costruire istruzioni SQL dinamiche, utilizzare EXECUTE.

Funzionerebbe come ti aspettavi se, ad esempio, avessi usato la tua variabile in una clausola where. Per quanto riguarda il motivo, penso che abbia qualcosa a che fare con il parser non in grado di valutare la variabile e quindi verificare l'esistenza. Durante l'esecuzione, la query viene prima analizzata per la sintassi e gli oggetti e quindi, se l'analisi ha esito positivo, la query viene eseguita a quel punto in cui verrebbe impostata la variabile.

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

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

insert into #tmp
values('test')

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

Le limitazioni all'uso delle variabili nelle istruzioni SQL derivano dall'architettura di SQL.

Esistono tre fasi nell'elaborazione di un'istruzione SQL:

1. Preparazione: l'istruzione viene analizzata e viene compilato un piano di esecuzione , che specifica a quali oggetti del database si accede, come sono accessibili e come sono correlati. Il piano di esecuzione viene salvato nella cache del piano .
2. Binding: qualsiasi variabile nell'istruzione viene sostituita con valori effettivi.
3. Esecuzione: il piano memorizzato nella cache viene eseguito con i valori associati.

Il server SQL nasconde la fase di preparazione dal programmatore e lo esegue molto più velocemente rispetto ai database più tradizionali come Oracle e DB2. È per motivi di prestazioni che SQL impiega potenzialmente molto tempo a determinare un piano di esecuzione ottimale, ma lo fa solo la prima volta che si incontra l'istruzione dopo un riavvio.

Pertanto , nell'SQL statico , le variabili possono essere utilizzate solo in luoghi in cui non invalideranno il piano di esecuzione, quindi non per i nomi delle tabelle, i nomi delle colonne (inclusi i nomi delle colonne nelle condizioni WHERE), ecc.

SQL dinamico esiste per i casi in cui non è possibile aggirare le restrizioni e il programmatore sa che l'esecuzione richiederà leggermente più tempo. SQL dinamico può essere vulnerabile all'iniezione di codice dannoso, quindi fai attenzione!

Come puoi vedere, la domanda "perché" richiede un diverso tipo di risposta, tra cui la logica storica e le ipotesi alla base della lingua, non sono sicuro di poter davvero rendere giustizia.

Questo articolo completo di SQL MVP Erland Sommarskog tenta di fornire alcune motivazioni, insieme alla meccanica:

The Curse and Blessings of Dynamic SQL :

Piani di query nella cache

Ogni query eseguita in SQL Server richiede un piano di query. Quando si esegue una query per la prima volta, SQL Server crea un piano di query per esso - o secondo la terminologia - compila la query. SQL Server salva il piano nella cache e alla successiva esecuzione della query, il piano viene riutilizzato.

Questo (e la sicurezza, vedi sotto) è probabilmente il motivo principale.

SQL funziona con la premessa che le query non sono operazioni singole, ma che verranno utilizzate più e più volte. Se la tabella (o il database!) Non è effettivamente specificata nella query, non ha modo di generare e salvare un piano di esecuzione per uso futuro.

Sì, non tutte le query che eseguiremo verranno riutilizzate, ma questa è la premessa operativa predefinita di SQL , quindi "eccezioni" sono considerate eccezionali.

Alcuni altri motivi elencati da Erland (si noti che elenca esplicitamente i vantaggi dell'utilizzo di stored procedure , ma molti di questi sono anche vantaggi delle query con parametri (non dinamici):

• Il sistema di autorizzazione : il motore SQL non è in grado di prevedere se si dispone dei diritti per eseguire una query se non conosce la tabella (o il database) su cui si opererà. Le "catene di autorizzazioni" che usano l'SQL dinamico sono una seccatura.
• Riduzione del traffico di rete : il passaggio del nome del proc memorizzato e alcuni valori di parametro sulla rete sono più brevi di un'istruzione di query lunga.
• Logica incapsulante : dovresti conoscere i vantaggi dell'incapsulamento della logica da altri ambienti di programmazione.
• Tenere traccia di ciò che viene utilizzato : se devo modificare una definizione di colonna, come posso trovare tutto il codice che lo chiama? Esistono procedure di sistema per trovare dipendenze all'interno di un database SQL, ma solo se il codice è nelle stored procedure.
• Facilità di scrittura del codice SQL : il controllo della sintassi si verifica quando si crea o si modifica una procedura memorizzata, quindi si spera che si verifichino meno errori.
• Risoluzione di bug e problemi : un DBA può tracciare e misurare le prestazioni delle singole procedure memorizzate molto più facilmente rispetto all'SQL dinamico in continua evoluzione.

Ancora una volta, ognuna di queste ha cento sfumature che non entrerò qui.

Devi usare sql dinamico

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

di seguito è riportato l'output di stampa .. una volta decommentata, exec sp_executesql @sqltextle istruzioni verranno effettivamente eseguite ...

CREATE DATABASE [dbamaint];
use [dbamaint];