¿Por qué no puedo usar variables en T-SQL como imagino que puedo?

Perdóname, soy un desarrollador que se ha mudado al mundo de SQL. Pensé que podría mejorar algunos SQL agregando variables, pero no funcionó como esperaba. ¿Alguien puede decirme por qué esto no funciona? No quiero una solución, quiero saber las razones por las que esto no funciona como imagino que debería, ya que estoy seguro de que hay una buena razón, pero actualmente no me sorprende.

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

CREATE DATABASE @DatabaseName
GO

USE @DatabaseName
GO

Por la página de libros en línea para variables

Las variables se pueden usar solo en expresiones, no en lugar de nombres de objetos o palabras clave. Para construir sentencias SQL dinámicas, use EXECUTE.

Funcionaría de la manera que esperaba si, por ejemplo, usara su variable en una cláusula where. En cuanto a por qué, creo que tiene algo que ver con el analizador no capaz de evaluar la variable y, por lo tanto, verificar su existencia. Al ejecutar, la consulta se analiza primero para la sintaxis y los objetos y luego, si el análisis es exitoso, la consulta se ejecuta en ese punto, la variable se establecería.

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

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

insert into #tmp
values('test')

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

Las limitaciones en el uso de variables en las declaraciones SQL surgen de la arquitectura de SQL.

Hay tres fases en el procesamiento de una declaración SQL:

1. Preparación: la instrucción se analiza y se compila un plan de ejecución , que especifica a qué objetos de la base de datos se accede, cómo se accede y cómo se relacionan. El plan de ejecución se guarda en la caché del plan .
2. Enlace: todas las variables en la declaración se reemplazan con valores reales.
3. Ejecución: el plan en caché se ejecuta con los valores enlazados.

El servidor SQL oculta el paso de preparación del programador y lo ejecuta mucho más rápido que las bases de datos más tradicionales como Oracle y DB2. Es por razones de rendimiento que SQL pasa potencialmente mucho tiempo determinando un plan de ejecución óptimo, pero solo lo hace la primera vez que se encuentra la declaración después de un reinicio.

Por lo tanto, en SQL estático , las variables solo se pueden usar en lugares donde no invaliden el plan de ejecución, por lo que no para nombres de tablas, nombres de columnas (incluidos los nombres de columnas en condiciones WHERE), etc.

El SQL dinámico existe para los casos en los que no se pueden evitar las restricciones, y el programador sabe que la ejecución tardará un poco más. El SQL dinámico puede ser vulnerable a la inyección de código malicioso, ¡así que tenga cuidado!

Como puede ver, la pregunta "por qué" requiere un tipo diferente de respuesta, que incluye la justificación histórica y los supuestos subyacentes para el lenguaje, no estoy seguro de que realmente pueda hacer esa justicia.

Este completo artículo del MVP de SQL Erland Sommarskog intenta proporcionar algunos fundamentos, junto con la mecánica:

La maldición y las bendiciones del SQL dinámico :

Planes de consulta de almacenamiento en caché

Cada consulta que ejecuta en SQL Server requiere un plan de consulta. Cuando ejecuta una consulta por primera vez, SQL Server crea un plan de consulta para ella, o según la terminología, compila la consulta. SQL Server guarda el plan en caché y la próxima vez que ejecute la consulta, el plan se reutiliza.

Esto (y la seguridad, ver más abajo) es probablemente la razón más importante.

SQL opera bajo la premisa de que las consultas no son operaciones únicas, sino que se utilizarán una y otra vez. Si la tabla (¡o la base de datos!) No se especifica realmente en la consulta, no tiene forma de generar y guardar un plan de ejecución para uso futuro.

Sí, no todas las consultas que ejecutamos se reutilizarán, pero esta es la premisa operativa predeterminada de SQL , por lo que las "excepciones" deben ser excepcionales.

Algunas otras razones que Erland enumera (tenga en cuenta que enumera explícitamente las ventajas de usar procedimientos almacenados , pero muchas de estas también son ventajas de consultas parametrizadas (no dinámicas)):

• El sistema de permisos : el motor SQL no puede predecir si tiene los derechos para ejecutar una consulta si no conoce la tabla (o base de datos) con la que va a operar. Las "cadenas de permisos" que usan SQL dinámico son un fastidio.
• Reducción del tráfico de red : pasar el nombre del proceso almacenado y algunos valores de parámetros a través de la red es más corto que una declaración de consulta larga.
• Lógica de encapsulación : debe estar familiarizado con las ventajas de encapsular la lógica de otros entornos de programación.
• Seguimiento de lo que se usa : si necesito cambiar la definición de una columna, ¿cómo puedo encontrar todo el código que la llama? Los procedimientos del sistema existen para encontrar dependencias dentro de una base de datos SQL, pero solo si el código está en procedimientos almacenados.
• Facilidad de escritura del código SQL : la verificación de sintaxis se produce al crear o modificar un procedimiento almacenado, por lo que es de esperar que se produzcan menos errores.
• Abordar errores y problemas : un DBA puede rastrear y medir el rendimiento de los procedimientos almacenados individuales mucho más fácilmente que el SQL dinámico que cambia constantemente.

Una vez más, cada uno de estos tiene un centenar de matices en los que no entraré aquí.

Necesitas 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

a continuación se muestra la salida de impresión ... una vez que elimine el comentario, exec sp_executesql @sqltextlas declaraciones se ejecutarán realmente ...

CREATE DATABASE [dbamaint];
use [dbamaint];