내가 상상하는 것처럼 T-SQL에서 변수를 사용할 수없는 이유는 무엇입니까?

용서하십시오, 저는 SQL의 세계로 옮긴 개발자입니다. 변수를 추가하여 SQL을 향상시킬 수 있다고 생각했지만 예상대로 작동하지 않았습니다. 왜 이것이 작동하지 않는지 말해 줄 수 있습니까? 나는 해결책을 원하지 않고, 나는 그것이 좋은 이유가 있다고 확신 할 때 상상 해야하는 것처럼 작동하지 않는 이유를 알고 싶다. 그러나 현재 나에게 튀어 오르지 않는다.

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

CREATE DATABASE @DatabaseName
GO

USE @DatabaseName
GO

변수에 대한 온라인 설명서 페이지

변수는 객체 이름이나 키워드 대신 표현식에서만 사용할 수 있습니다. 동적 SQL 문을 구성하려면 EXECUTE를 사용하십시오.

예를 들어 where 절에서 변수를 사용한 경우 예상했던대로 작동합니다. 이유에 관해서는 변수가 변수를 평가할 수 없어 파서와 관련이 있다고 생각합니다. 실행시 구문과 객체에 대해 쿼리를 먼저 구문 분석 한 다음 구문 분석에 성공하면 변수가 설정된 시점에서 쿼리가 실행됩니다.

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

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

insert into #tmp
values('test')

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

SQL 문에서 변수 사용에 대한 제한 사항은 SQL 아키텍처에서 발생합니다.

SQL 문 처리에는 세 단계가 있습니다.

1. 준비-명령문을 구문 분석하고 실행 계획 을 컴파일하여 액세스 할 데이터베이스 오브젝트, 액세스 방법 및 관련 방법을 지정합니다. 실행 계획은 계획 캐시에 저장 됩니다 .
2. 바인딩-명령문의 모든 변수가 실제 값으로 바뀝니다.
3. 실행-캐시 된 계획이 바인딩 된 값으로 실행됩니다.

SQL Server는 프로그래머로부터 준비 단계를 숨기고 Oracle 및 DB2와 같은 기존의 데이터베이스보다 훨씬 빠르게 실행합니다. 성능상의 이유로 SQL이 잠재적으로 최적의 실행 계획을 결정하는 데 많은 시간을 소비하지만 재시작 후 명령문이 처음 발생할 때만 수행합니다.

따라서 정적 SQL 에서는 변수가 실행 계획을 무효화하지 않는 위치에서만 사용할 수 있으므로 테이블 이름, 열 이름 (WHERE 조건의 열 이름 포함) 등이 아닙니다.

동적 SQL 은 제한 사항을 처리 할 수없는 경우에 존재하며 프로그래머는 실행하는 데 약간 더 오래 걸릴 것임을 알고 있습니다. 동적 SQL은 악성 코드 삽입에 취약 할 수 있으므로주의하십시오!

보시다시피 "이유"질문에는 역사적 근거와 언어에 대한 기본 가정을 포함하여 다른 종류의 답변이 필요합니다.

SQL MVP Erland Sommarskog의이 포괄적 인 기사는 메커니즘과 함께 몇 가지 이론적 근거를 제공하려고 시도합니다.

동적 SQL의 저주와 축복 :

쿼리 계획 캐싱

SQL Server에서 실행하는 모든 쿼리에는 쿼리 계획이 필요합니다. 쿼리를 처음 실행할 때 SQL Server는 쿼리 계획을 작성하거나 용어에 따라 쿼리를 컴파일합니다. SQL Server는 계획을 캐시에 저장하고 다음에 쿼리를 실행할 때 계획이 재사용됩니다.

이것이 (그리고 보안, 아래 참조) 아마도 가장 큰 이유 일 것입니다.

SQL은 쿼리가 일회성 작업이 아니라 계속 사용된다는 전제 하에서 작동합니다. 테이블 (또는 데이터베이스!)이 실제로 쿼리에 지정되어 있지 않으면 나중에 사용할 수 있도록 실행 계획을 생성하고 저장할 수 없습니다.

예, 우리가 실행하는 모든 쿼리가 재사용되는 것은 아니지만 이것이 SQL의 기본 운영 전제 이므로 "예외"는 예외적입니다.

Erland가 나열하는 몇 가지 다른 이유 ( 저장 프로 시저 사용의 장점을 명시 적으로 나열 하고 있지만 매개 변수화 된 (비 동적) 쿼리의 장점이기도합니다)

• 권한 시스템 : SQL 엔진은 조작 할 테이블 (또는 데이터베이스)을 모르는 경우 쿼리를 실행할 권한이 있는지 여부를 예측할 수 없습니다. 동적 SQL을 사용하는 "권한 체인"은 문제가 많습니다.
• 네트워크 트래픽 줄이기 : 저장된 proc의 이름과 몇 개의 매개 변수 값을 네트워크를 통해 전달하는 것은 긴 쿼리 문보다 짧습니다.
• 캡슐화 로직 : 다른 프로그래밍 환경에서 로직을 캡슐화하는 이점에 익숙해야합니다.
• 사용 된 내용 추적 : 열 정의를 변경해야하는 경우이를 호출하는 모든 코드를 어떻게 찾을 수 있습니까? 시스템 프로시 저는 SQL 데이터베이스 내에서 종속성을 찾기 위해 존재하지만 코드가 저장 프로 시저에있는 경우에만 존재합니다.
• SQL 코드 작성 용이성 : 저장 프로 시저를 만들거나 수정할 때 구문 검사가 발생하므로 오류가 거의 발생하지 않습니다.
• 버그 및 문제 해결 : DBA는 변화하는 동적 SQL보다 훨씬 쉽게 개별 저장 프로 시저의 성능을 추적하고 측정 할 수 있습니다.

다시, 이것들 각각은 내가 여기에 들어 가지 않을 백 개의 뉘앙스를 가지고 있습니다.

동적 SQL을 사용해야합니다

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

아래는 print.의 출력입니다. 주석을 해제 exec sp_executesql @sqltext하면 명령문이 실제로 실행됩니다 ...

CREATE DATABASE [dbamaint];
use [dbamaint];