Warum kann ich in T-SQL keine Variablen verwenden, wie ich es mir vorstelle?

Verzeih mir, ich bin ein Entwickler, der in die Welt von SQL gewechselt ist. Ich dachte, ich könnte etwas SQL verbessern, indem ich Variablen hinzufüge, aber es funktionierte nicht so, wie ich es erwartet hatte. Kann mir jemand sagen warum das nicht geht? Ich möchte keine Abhilfe schaffen, ich möchte die Gründe wissen, warum dies nicht so funktioniert, wie ich es mir vorstelle, da ich mir sicher bin, dass es einen guten Grund gibt, aber momentan springt es mir nicht auf die Nerven.

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

CREATE DATABASE @DatabaseName
GO

USE @DatabaseName
GO

Per der Books Online-Seite für Variablen

Variablen können nur in Ausdrücken verwendet werden, nicht anstelle von Objektnamen oder Schlüsselwörtern. Verwenden Sie EXECUTE, um dynamische SQL-Anweisungen zu erstellen.

Es würde so funktionieren, wie Sie es erwartet hatten, wenn Sie beispielsweise Ihre Variable in einer where-Klausel verwenden würden. Was den Grund angeht, so hat dies vermutlich etwas mit dem Parser zu tun, der die Variable nicht auswerten und somit auf Existenz prüfen kann. Bei der Ausführung wird die Abfrage zuerst nach Syntax und Objekten analysiert. Wenn die Analyse erfolgreich ist, wird die Abfrage ausgeführt, an welcher Stelle die Variable gesetzt wird.

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

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

insert into #tmp
values('test')

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

Die Einschränkungen bei der Verwendung von Variablen in SQL-Anweisungen ergeben sich aus der Architektur von SQL.

Die Verarbeitung einer SQL-Anweisung umfasst drei Phasen:

1. Vorbereitung - Die Anweisung wird analysiert und ein Ausführungsplan erstellt, in dem angegeben wird, auf welche Datenbankobjekte zugegriffen wird, wie auf sie zugegriffen wird und in welcher Beziehung sie zueinander stehen. Der Ausführungsplan wird im Plan-Cache gespeichert .
2. Bindung - Alle Variablen in der Anweisung werden durch tatsächliche Werte ersetzt.
3. Ausführung - Der zwischengespeicherte Plan wird mit den gebundenen Werten ausgeführt.

SQL Server verbirgt den Vorbereitungsschritt vor dem Programmierer und führt ihn viel schneller aus als herkömmliche Datenbanken wie Oracle und DB2. Aus Performancegründen verbringt SQL möglicherweise viel Zeit damit, einen optimalen Ausführungsplan zu bestimmen, dies jedoch nur, wenn die Anweisung zum ersten Mal nach einem Neustart auftritt.

In statischem SQL dürfen Variablen daher nur an Stellen verwendet werden, an denen sie den Ausführungsplan nicht ungültig machen, also nicht für Tabellennamen, Spaltennamen (einschließlich Spaltennamen in WHERE-Bedingungen) usw.

Dynamisches SQL gibt es für Fälle, in denen man die Einschränkungen nicht umgehen kann und der Programmierer weiß, dass die Ausführung etwas länger dauert. Dynamic SQL kann anfällig für bösartigen Code sein. Seien Sie also vorsichtig!

Wie Sie sehen, erfordert die "Warum" -Frage eine andere Art von Antwort, einschließlich historischer Gründe und zugrunde liegender Annahmen für die Sprache. Ich bin mir nicht sicher, ob ich dieser Frage wirklich gerecht werden kann.

In diesem umfassenden Artikel von SQL MVP Erland Sommarskog wird versucht, einige Gründe zusammen mit den Mechanismen anzugeben:

Der Fluch und der Segen von Dynamic SQL :

Abfragepläne zwischenspeichern

Für jede Abfrage, die Sie in SQL Server ausführen, ist ein Abfrageplan erforderlich. Wenn Sie eine Abfrage zum ersten Mal ausführen, erstellt SQL Server einen Abfrageplan für diese Abfrage. Je nach Terminologie wird die Abfrage kompiliert. SQL Server speichert den Plan im Cache. Wenn Sie die Abfrage das nächste Mal ausführen, wird der Plan wiederverwendet.

Dies (und die Sicherheit, siehe unten) ist wahrscheinlich der Hauptgrund.

SQL geht davon aus, dass Abfragen keine einmaligen Vorgänge sind, sondern immer wieder verwendet werden. Wenn die Tabelle (oder die Datenbank!) Nicht tatsächlich in der Abfrage angegeben ist, kann kein Ausführungsplan für die zukünftige Verwendung generiert und gespeichert werden.

Ja, nicht jede Abfrage, die wir ausführen, wird wiederverwendet. Dies ist jedoch die Standardvoraussetzung für SQL , sodass "Ausnahmen" als außergewöhnlich angesehen werden.

Einige andere Gründe, die Erland aufführt (beachten Sie, dass er die Vorteile der Verwendung gespeicherter Prozeduren explizit auflistet , aber viele davon sind auch Vorteile parametrisierter (nicht dynamischer) Abfragen):

• Das Berechtigungssystem : Die SQL-Steuerkomponente kann nicht vorhersagen, ob Sie zum Ausführen einer Abfrage berechtigt sind, wenn sie die Tabelle (oder Datenbank) nicht kennt, mit der Sie arbeiten werden. "Berechtigungsketten" mit dynamischem SQL sind ein Problem.
• Reduzieren des Netzwerkverkehrs : Das Übergeben des Namens des gespeicherten Prozesses und einiger Parameterwerte über das Netzwerk ist kürzer als eine lange Abfrageanweisung.
• Kapselungslogik : Sie sollten mit den Vorteilen der Kapselung von Logik aus anderen Programmierumgebungen vertraut sein.
• Verfolgen, was verwendet wird : Wenn ich eine Spaltendefinition ändern muss, wie kann ich den gesamten Code finden, der sie aufruft? Systemprozeduren sind vorhanden, um Abhängigkeiten in einer SQL-Datenbank zu finden, jedoch nur, wenn sich der Code in gespeicherten Prozeduren befindet.
• Einfache Erstellung von SQL-Code : Die Syntaxprüfung erfolgt beim Erstellen oder Ändern einer gespeicherten Prozedur, sodass hoffentlich weniger Fehler auftreten.
• Beheben von Fehlern und Problemen : Ein DBA kann die Leistung einzelner gespeicherter Prozeduren viel einfacher verfolgen und messen als sich ständig änderndes dynamisches SQL.

Auch hier hat jede hundert Nuancen, auf die ich hier nicht eingehen werde.

Sie müssen dynamisches SQL verwenden

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

Unten ist die Ausgabe von print. Sobald Sie das Kommentarzeichen entfernen, werden exec sp_executesql @sqltextdie Anweisungen tatsächlich ausgeführt.

CREATE DATABASE [dbamaint];
use [dbamaint];