As visualizações são logicamente redundantes?

Tanto as visualizações quanto os TVFs in-line são atualizáveis ​​e podem ser usados ​​de forma intercambiável em quase todos os lugares.

Especificamente para SQL Server, os seguintes recursos têm suporte em exibições que não estão disponíveis para TVFs embutidos:

• WITH CHECK OPTION, uma opção pouco usada que impede atualizações em linhas em uma visualização atualizável, o que resultaria na exclusão dessa linha da visualização.
• Visualizações indexadas, que permitem que uma visualização seja materializada e indexada.
  Os TVFs ainda podem usar essas visualizações (mesmo implicitamente), mas você não pode indexar um TVF diretamente.
• bcp.exenão é possível consultar a partir de um TVF sem uma SELECTconsulta real.
• A maioria dos clientes GUI não mostrará um TVF como navegável em uma visualização em grade, mesmo que não tenha parâmetros. Você precisaria escrever uma SELECTconsulta e as modificações podem não funcionar.
• Alguns clientes entendem melhor as definições de coluna quando vêm de uma visualização (como ao usar sp_describe_first_result_set).

Obviamente, os TVFs podem usar parâmetros, o que as visualizações não podem. Muitas vezes, isso pode torná-lo muito mais eficiente do que uma visualização semelhante seria, por exemplo, ao inserir predicados em funções de janela . Eles também podem ser APPLYcriados linha por linha, em vez de usar junções, o que pode torná-los muito mais flexíveis.

Você deve usar um em vez do outro? Acho que um TVF sem parâmetros não faz muito sentido. Você não pode indexá-lo, então precisará repetir o código se quiser. Também é mais idiomático usar uma visualização e elas são mais óbvias para os usuários. O Intellisense em alguns IDEs também não funciona bem com funções.

Não use TVFs com múltiplas instruções ou UDFs escalares, a menos que você não possa evitá-los, pois ambos costumam ser um grande problema de desempenho.

Fundo

Os conceitos dos principais mecanismos de banco de dados SQL evoluíram gradualmente ao longo de décadas para atender às necessidades mais importantes da época, e também houve uma série de padrões industriais que definem a funcionalidade básica, que são difíceis de revisar uma vez estabelecidos.

O resultado é que nem sempre é fácil compreender a lógica do design.

O conceito de "visão" existe, até onde sei, desde o início da história do SQL, possivelmente desde o início - de qualquer forma, é certamente um dos conceitos mais antigos. Enquanto isso, funções com valor de tabela, com a possibilidade de argumentos fornecidos, são uma adição muito posterior ao SQL e não tenho certeza de quão padrão elas são.

Visualizações

As visualizações executam diversas funções.

A principal delas é fornecer uma camada indireta para tabelas, para que o esquema de armazenamento subjacente possa ser adaptado mais facilmente sem quebrar o código existente. Sintaticamente, o SQL não diferencia entre referência a uma visualização e referência a uma tabela, e uma visualização pode (sob certas restrições) ser o alvo de uma inserção, atualização ou exclusão , exatamente como uma tabela pode ser.

Outro propósito das visualizações é atuar como um objeto protegível que é distinto da tabela subjacente, de modo que dados filtrados ou resumidos possam ser fornecidos e o acesso a eles controlado, independentemente da tabela base.

Alguns motores também fornecem visualizações "indexadas" ou "materializadas" , nas quais os resultados de uma consulta são preparados e armazenados pelo motor separadamente da ocasião em que os resultados são solicitados, e podem ser mantidos atualizados pelo motor de banco de dados que analisa a linhagem dos resultados e responde às alterações nos dados de origem, atualizando automaticamente os resultados armazenados.

Um propósito para o qual acho que as visualizações não foram originalmente projetadas foi a modularidade do código SQL puramente como uma conveniência para o programador. A linguagem SQL já foi consideravelmente mais limitada em capacidade do que é agora na maioria dos mecanismos, assim como o desempenho do maquinário que hospedava um mecanismo de banco de dados, e normalmente não haveria muita complexidade intrínseca no código SQL de uma visão em si. Hoje em dia, no entanto, as visualizações podem ser utilizadas assim, encapsulando um trecho de código SQL que é comum a muitas consultas e complexo de uma forma que torna a duplicação irracional.

Funções com valor de tabela

O objetivo das funções com valor de tabela é apenas extrair dados , ao passo que esse não é o único propósito das visualizações, que também podem acomodar a inserção de dados.

No SQL Server, com o qual estou mais familiarizado, também há uma distinção entre funções "inline" e funções "multi-instruções".

Apenas o caso de uma função embutida e sem parâmetros se assemelha muito a uma visualização. Uma função com múltiplas instruções se assemelha mais a um procedimento armazenado do que a uma visualização , mas, ao contrário de um procedimento, pode participar de uma consulta de maneira semelhante a uma tabela ou visualização.

(EDITAR: De acordo com um comentário de @Charlieface, e como uma qualificação ao ponto sobre "obter dados", embora este ponto seja verdadeiro para funções com múltiplas instruções, parece que TVFs in-line podem de fato ser "atualizáveis" como as visualizações podem ser.)

Por que a sobreposição?

Você já pode ver que os propósitos principais que as visualizações cumprem não se ajustam perfeitamente aos das funções parametrizadas, mesmo no caso degenerado sem parâmetros.

Não tenho certeza se existe algum caso em que uma função embutida e sem parâmetros não seja totalmente intercambiável com uma visualização. Suspeito que esse caso de sobreposição seja permitido apenas para completar o conceito de "função" e porque surge naturalmente, sem complexidade adicional ou esforço de implementação.

Uma função de múltiplas instruções pode, no entanto, alcançar coisas que uma visão claramente não conseguiria (ou pelo menos, poderia não conseguir sem código relativamente longo, distorcido e sem desempenho, e talvez não conseguiria sem muitos dos recursos mais recentes da linguagem SQL)

Resumo

Em resumo, visualizações e funções surgiram em momentos diferentes na evolução do SQL e cobrem principalmente propósitos diferentes. A pequena quantidade de sobreposição que existe não significa nem remotamente que um deles inclua totalmente todos os propósitos do outro.

A diferença essencial é que uma visão representa uma tabela inteira e tem muitas qualidades semelhantes às de uma tabela (incluindo equivalência sintática a uma tabela, funcionalidade de leitura/gravação e a capacidade de atribuir gatilhos), enquanto uma função representa um elemento reutilizável apenas de uma consulta Select.

Em geral, faço uso justo de visualizações para muitos propósitos diferentes, mas raramente uso funções (pois são um conceito muito mais pesado em SQL do que "funções", ou métodos, seriam em outras linguagens de programação).