As funções com valor de tabela são "apenas" visualizações parametrizadas. Isso os torna extremamente poderosos para encapsular a lógica que, de outra forma, estaria oculta por trás de um procedimento armazenado opaco. Aqui está um exemplo:
Função com valor de tabela inline:
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)
);
Procedimento armazenado:
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;
Ao contrário da chamada de procedimento armazenado, uma função com valor de tabela me permite compor a lógica de
dbo.GetClients com outros objetos:select *
from dbo.GetClients(N'ACME') as a
join ... as b
on a.ClientId = b.ClientId
Em tais situações, não consigo imaginar usar um procedimento armazenado por causa de quão restritivo ele é quando comparado à função com valor de tabela. Eu seria forçado a organizar os dados em torno de mim usando uma tabela temporária, variável de tabela ou camada de aplicativo para combinar resultados de vários objetos.
Funções com valor de tabela inline são especialmente impressionantes por causa do bit "inline" que provavelmente é melhor explicado aqui. Isso permite que o otimizador trate tais funções da mesma forma que os objetos que eles encapsulam, resultando em planos de desempenho quase ideais (supondo que seus índices e estatísticas sejam ideais).
