Funkcje wyceniane w tabeli są „tylko” sparametryzowanymi widokami. Dzięki temu są niezwykle wydajne w hermetyzowaniu logiki, która w przeciwnym razie byłaby ukryta za nieprzezroczystą procedurą składowaną. Oto przykład:
Wbudowana funkcja o wartości tabeli:
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)
);
Procedura przechowywana:
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;
W przeciwieństwie do wywołania procedury składowanej funkcja zwracająca tabelę pozwala mi skomponować logikę z dbo.GetClients z innymi obiektami:
select *
from dbo.GetClients(N'ACME') as a
join ... as b
on a.ClientId = b.ClientId
W takich sytuacjach nie wyobrażam sobie używania procedury składowanej ze względu na to, jak bardzo jest restrykcyjna w porównaniu z funkcją z wartościami przechowywanymi w tabeli. Byłbym zmuszony do zebrania danych wokół siebie za pomocą tabeli tymczasowej, zmiennej tabeli lub warstwy aplikacji w celu połączenia wyników z wielu obiektów.
Funkcje inline z wartościami tabelarycznymi są szczególnie niesamowite ze względu na bit „inline”, który prawdopodobnie najlepiej wyjaśniono tutaj. Pozwala to optymalizatorowi traktować takie funkcje nie inaczej niż obiekty, które enkapsulują, co skutkuje niemal optymalnymi planami wydajności (przy założeniu, że Twoje indeksy i statystyki są idealne).
