Chức năng và thủ tục lưu trữ phục vụ các mục đích riêng biệt. Mặc dù nó không phải là sự tương tự tốt nhất, các hàm có thể được xem theo nghĩa đen như bất kỳ chức năng nào khác mà bạn sử dụng trong bất kỳ ngôn ngữ lập trình nào, nhưng các procs được lưu trữ giống như các chương trình riêng lẻ hoặc một tập lệnh bó.
Các chức năng thường có một đầu ra và đầu vào tùy chọn. Đầu ra sau đó có thể được sử dụng làm đầu vào cho một chức năng khác (Máy chủ SQL tích hợp sẵn như DATEDIFF, LEN, v.v.) hoặc làm vị ngữ cho Truy vấn SQL - ví dụ: SELECT a, b, dbo.MyFunction(c) FROM tablehoặc SELECT a, b, c FROM table WHERE a = dbo.MyFunc(c).
Các procs được lưu trữ được sử dụng để liên kết các truy vấn SQL với nhau trong một giao dịch và giao diện với thế giới bên ngoài. Các khung như ADO.NET, v.v. không thể gọi hàm trực tiếp, nhưng chúng có thể gọi trực tiếp một Proc được lưu trữ.
Các chức năng có một mối nguy hiểm tiềm ẩn: chúng có thể bị sử dụng sai và gây ra các vấn đề hiệu suất khá khó chịu: xem xét truy vấn này:
SELECT * FROM dbo.MyTable WHERE col1 = dbo.MyFunction(col2)
Trường hợp MyFactor được khai báo là:
CREATE FUNCTION MyFunction (@someValue INTEGER) RETURNS INTEGER
AS
BEGIN
DECLARE @retval INTEGER
SELECT localValue
FROM dbo.localToNationalMapTable
WHERE nationalValue = @someValue
RETURN @retval
END
Điều xảy ra ở đây là hàm MyFunction được gọi cho mỗi hàng trong bảng MyTable. Nếu MyTable có 1000 hàng, thì đó là 1000 truy vấn đặc biệt khác đối với cơ sở dữ liệu. Tương tự, nếu hàm được gọi khi được chỉ định trong thông số cột, thì hàm sẽ được gọi cho mỗi hàng được trả về bởi SELECT.
Vì vậy, bạn cần phải cẩn thận chức năng viết. Nếu bạn thực hiện CHỌN từ một bảng trong một hàm, bạn cần tự hỏi liệu nó có thể được thực hiện tốt hơn với THAM GIA trong phần lưu trữ cha mẹ hoặc một số cấu trúc SQL khác (như CASE ... KHI ... ELSE ... KẾT THÚC).