Tabellvärdade funktioner är "bara" parametriserade vyer. Detta gör dem extremt kraftfulla för att kapsla in logik som annars skulle döljas bakom en ogenomskinlig lagrad procedur. Här är ett exempel:
Inline tabellvärderad funktion:
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)
);
Lagrad procedur:
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;
Till skillnad från det lagrade proceduranropet tillåter en tabellvärderad funktion mig att komponera logiken från dbo.GetClients
med andra objekt:
select *
from dbo.GetClients(N'ACME') as a
join ... as b
on a.ClientId = b.ClientId
I sådana situationer kan jag inte föreställa mig att använda en lagrad procedur på grund av hur restriktiv den är jämfört med den tabellvärderade funktionen. Jag skulle bli tvungen att samla data runt mig själv med hjälp av en temporär tabell, tabellvariabel eller applikationslager för att kombinera resultat från flera objekt.
Inline-tabellvärderade funktioner är särskilt fantastiska på grund av den "inline"-biten som förmodligen förklaras bäst här. Detta gör att optimeraren inte kan behandla sådana funktioner annorlunda än de objekt de kapslar in, vilket resulterar i nästan optimala prestationsplaner (förutsatt att dina index och statistik är idealiska).