Tabellenwertfunktionen sind "nur" parametrisierte Ansichten. Dies macht sie äußerst leistungsfähig zum Kapseln von Logik, die sonst hinter einer undurchsichtigen gespeicherten Prozedur verborgen wäre. Hier ist ein Beispiel:
Inline-Tabellenwertfunktion:
create function dbo.GetClients (
@clientName nvarchar(max) = null
)
returns table
return (
select *
from dbo.Clients as a
where ((a.ClientName = @clientName) or a.ClientName is null)
);
Gespeicherte Prozedur:
create procedure dbo.usp_GetClients (
@clientName nvarchar(max) = null
)
as
begin;
select *
from dbo.Clients as a
where ((a.ClientName = @clientName) or a.ClientName is null)
end;
Im Gegensatz zum Aufruf einer gespeicherten Prozedur ermöglicht mir eine Tabellenwertfunktion, die Logik aus dbo.GetClients
zu erstellen mit anderen Objekten:
select *
from dbo.GetClients(N'ACME') as a
join ... as b
on a.ClientId = b.ClientId
In solchen Situationen kann ich mir nicht vorstellen, eine gespeicherte Prozedur zu verwenden, da sie im Vergleich zur Tabellenwertfunktion so restriktiv ist. Ich wäre gezwungen, die Daten mithilfe einer temporären Tabelle, einer Tabellenvariablen oder einer Anwendungsschicht um mich herum zu ordnen, um die Ergebnisse mehrerer Objekte zu kombinieren.
Inline-Tabellenwertfunktionen sind wegen des "Inline"-Bits besonders großartig, das hier wahrscheinlich am besten erklärt wird. Dadurch kann der Optimierer solche Funktionen nicht anders behandeln als die Objekte, die sie verkapseln, was zu nahezu optimalen Leistungsplänen führt (unter der Annahme, dass Ihre Indizes und Statistiken ideal sind).