Tại sao tôi không thể sử dụng các biến trong T-SQL như tôi tưởng tượng?

Xin lỗi, tôi là một nhà phát triển đã chuyển sang thế giới của SQL. Tôi nghĩ rằng tôi có thể cải thiện một số SQL bằng cách thêm các biến nhưng nó không hoạt động như tôi mong đợi. Ai đó có thể cho tôi biết tại sao điều này không hoạt động? Tôi không muốn làm việc xung quanh, tôi muốn biết lý do tại sao điều này không hoạt động như tôi tưởng tượng vì tôi chắc chắn có một lý do chính đáng, nhưng hiện tại nó không nhảy ra khỏi tôi.

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

CREATE DATABASE @DatabaseName
GO

USE @DatabaseName
GO

Trên trang Sách trực tuyến cho các biến

Các biến chỉ có thể được sử dụng trong các biểu thức, không thay cho tên đối tượng hoặc từ khóa. Để xây dựng các câu lệnh SQL động, hãy sử dụng EXECUTE.

Nó sẽ hoạt động theo cách bạn mong đợi, ví dụ, nếu bạn sử dụng biến của mình trong mệnh đề where. Về lý do tại sao, tôi sẽ nghĩ rằng nó có liên quan đến trình phân tích cú pháp không thể đánh giá biến và do đó kiểm tra sự tồn tại. Khi thực hiện, truy vấn được phân tích cú pháp trước cho cú pháp và đối tượng và sau đó, nếu phân tích cú pháp thành công, truy vấn sẽ thực thi tại điểm mà biến sẽ được đặt.

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

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

insert into #tmp
values('test')

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

Các hạn chế về việc sử dụng các biến trong các câu lệnh SQL phát sinh từ kiến ​​trúc của SQL.

Có ba giai đoạn trong quá trình xử lý câu lệnh SQL:

1. Chuẩn bị - Câu lệnh được phân tích cú pháp và một kế hoạch thực hiện được biên dịch, chỉ định các đối tượng cơ sở dữ liệu nào được truy cập, cách chúng được truy cập và chúng có liên quan như thế nào. Kế hoạch thực hiện được lưu trong bộ đệm của kế hoạch .
2. Ràng buộc - bất kỳ biến nào trong câu lệnh được thay thế bằng các giá trị thực tế.
3. Thực thi - kế hoạch lưu trữ được thực hiện với các giá trị ràng buộc.

Máy chủ SQL ẩn bước chuẩn bị từ lập trình viên và thực thi nó nhanh hơn nhiều so với các cơ sở dữ liệu truyền thống như Oracle và DB2. Vì lý do hiệu năng mà SQL dành nhiều thời gian để xác định kế hoạch thực hiện tối ưu, nhưng chỉ thực hiện lần đầu tiên khi gặp câu lệnh sau khi khởi động lại.

Vì vậy, trong SQL tĩnh , các biến chỉ có thể được sử dụng ở những nơi chúng sẽ không làm mất hiệu lực kế hoạch thực hiện, vì vậy không phải cho tên bảng, tên cột (bao gồm cả tên cột trong điều kiện WHERE), v.v.

SQL động tồn tại cho các trường hợp mà người ta không thể làm việc với các hạn chế và lập trình viên biết rằng sẽ mất nhiều thời gian hơn để thực thi. SQL động có thể dễ bị tấn công bằng mã độc, vì vậy hãy cẩn thận!

Như bạn có thể thấy, câu hỏi "tại sao" đòi hỏi một loại câu trả lời khác, bao gồm cả lý do lịch sử và các giả định cơ bản cho ngôn ngữ, tôi không chắc mình thực sự có thể thực hiện công lý đó.

Bài viết toàn diện này của SQL MVP Erland Sommarskog không cố gắng cung cấp một số lý do, cùng với các cơ chế:

Lời nguyền và phước lành của SQL động :

Gói bộ nhớ truy vấn

Mỗi truy vấn bạn chạy trong SQL Server yêu cầu một kế hoạch truy vấn. Khi bạn chạy truy vấn lần đầu tiên, SQL Server sẽ xây dựng một kế hoạch truy vấn cho nó - hoặc theo thuật ngữ - nó sẽ biên dịch truy vấn. SQL Server lưu kế hoạch trong bộ đệm và lần sau khi bạn chạy truy vấn, kế hoạch được sử dụng lại.

Điều này (và bảo mật, xem bên dưới) có lẽ là lý do lớn nhất.

SQL hoạt động với tiền đề rằng các truy vấn không phải là hoạt động một lần, mà chúng sẽ được sử dụng nhiều lần. Nếu bảng (hoặc cơ sở dữ liệu!) Không thực sự được chỉ định trong truy vấn, thì không có cách nào để tạo và lưu kế hoạch thực hiện để sử dụng trong tương lai.

Có, không phải mọi truy vấn chúng tôi chạy sẽ được sử dụng lại, nhưng đây là tiền đề hoạt động mặc định của SQL , vì vậy "ngoại lệ" có nghĩa là đặc biệt.

Một vài lý do khác mà danh sách Erland (lưu ý rằng anh ta liệt kê rõ ràng lợi thế của việc sử dụng các thủ tục được lưu trữ , nhưng nhiều trong số đó cũng là lợi thế của các truy vấn được tham số hóa (không động)):

• Hệ thống cấp phép : công cụ SQL không thể dự đoán liệu bạn có quyền chạy truy vấn hay không nếu nó không biết bảng (hoặc cơ sở dữ liệu) mà bạn sẽ hoạt động. "Chuỗi quyền" sử dụng SQL động là một nỗi đau ở mông.
• Giảm lưu lượng mạng : Truyền tên của Proc được lưu trữ và một vài giá trị tham số qua mạng ngắn hơn một câu lệnh truy vấn dài.
• Logic đóng gói : Bạn nên làm quen với những lợi thế của việc đóng gói logic từ các môi trường lập trình khác.
• Theo dõi những gì được sử dụng : Nếu tôi cần thay đổi một định nghĩa cột, làm thế nào tôi có thể tìm thấy tất cả các mã gọi nó? Các thủ tục hệ thống tồn tại để tìm các phụ thuộc trong cơ sở dữ liệu SQL, nhưng chỉ khi mã nằm trong các thủ tục được lưu trữ.
• Dễ viết mã SQL : Kiểm tra cú pháp xảy ra khi bạn tạo hoặc sửa đổi một thủ tục được lưu trữ, do đó hy vọng sẽ có ít lỗi hơn.
• Giải quyết các lỗi và vấn đề : Một DBA có thể theo dõi và đo lường hiệu suất của các thủ tục được lưu trữ riêng lẻ dễ dàng hơn nhiều so với SQL động thay đổi liên tục.

Một lần nữa, mỗi trong số chúng có một trăm sắc thái mà tôi sẽ không nhận được ở đây.

Bạn cần sử dụng sql động

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

bên dưới là đầu ra của bản in .. một khi bạn bỏ ghi chú, exec sp_executesql @sqltextcác câu lệnh sẽ được thực thi ...

CREATE DATABASE [dbamaint];
use [dbamaint];