Como Simplificar Consultas Complexas com Views no SQL

Uma view em SQL é uma maneira alternativa de observação de dados de uma ou mais entidades (tabelas), que compõem uma base de dados. Pode ser considerada como uma tabela virtual ou uma consulta armazenada.

View é um resultado originado de uma consulta pré-definida. Essencialmente é um metadado que mapeia uma query para outra, por isto pode ser considerado como uma tabela virtual. Como o próprio nome diz, ela representa uma visão de dados e não contém dados. Com ela você tem a ilusão que está vendo uma tabela que não existe.

VAI GOSTAR:

Elas não são carregadas, elas são geradas sempre que forem necessárias.

A não ser que a view seja materializada, aí você terá tabelas reais representando essas views. Mas a carga delas ocorrerão conforme a necessidade e otimizações do banco de dados. Só neste tipo de view é que os dados são atualizados quando as tabelas reais sofrem atualizações (ao final deste artigo, veja a diferença).

Mas é importante notar que mesmo em uma view não materializada existe a ilusão de que uma atualização da tabela real envolvida reflita na view, afinal a view é gerada no momento que ela é necessária.

Essas tabelas virtuais são dinâmicas, elas só existem no momento em que você precisa delas. Somente a query para sua geração é pré-definida. Se um dado for atualizado logo em seguida uma view for acessada, essa atualização não será considerada neste momento, somente na próxima vez que a view for usada.

É bom entender que essa “tabela virtual” que é criada, não é bem uma tabela física criada em memória com todos os dados que você precisa. A view é apenas uma forma de traduzir uma query para outra query mais complexa. Mas uma otimização pode acabar tornando sim uma view comum em tabela física. Claro isto depende da implementação do DB.

Como Simplificar Consultas Complexas com Views no SQL

Uma view é muito usada para ajudar dar entendimento do projeto lógico do banco de dados.

Exemplo:

Aqui vemos uma view criada para facilitar o acesso aos funcionários que são de Seattle que. Desta forma é possível acessar as informações mais importantes destes funcionários de forma consolidada em uma “tabela virtual” chamada SeattleOnly.

Fazendo com que desta forma possuam todas as vantagens citadas abaixo.

CREATE VIEW dbo.SeattleOnly
AS
SELECT p.LastName, p.FirstName, e.JobTitle, a.City, sp.StateProvinceCode
FROM HumanResources.Employee e
INNER JOIN Person.Person p
ON p.BusinessEntityID = e.BusinessEntityID
    INNER JOIN Person.BusinessEntityAddress bea 
    ON bea.BusinessEntityID = e.BusinessEntityID 
    INNER JOIN Person.Address a 
    ON a.AddressID = bea.AddressID
    INNER JOIN Person.StateProvince sp 
    ON sp.StateProvinceID = a.StateProvinceID
WHERE a.City = 'Seattle'

Retirado do exemplo usando o banco AdventureWorks da Microsoft.

Exemplo de uso:

SELECT * FROM dbo.SeattleOnly WHERE LastName = 'Willians';

Note que retornará 4 colunas. No fundo isto é o mesmo que escrever:

SELECT p.LastName, p.FirstName, e.JobTitle, a.City, sp.StateProvinceCode
FROM HumanResources.Employee e
INNER JOIN Person.Person p
ON p.BusinessEntityID = e.BusinessEntityID
    INNER JOIN Person.BusinessEntityAddress bea 
    ON bea.BusinessEntityID = e.BusinessEntityID 
    INNER JOIN Person.Address a 
    ON a.AddressID = bea.AddressID
    INNER JOIN Person.StateProvince sp 
    ON sp.StateProvinceID = a.StateProvinceID
WHERE a.City = 'Seattle' AND p.LastName = 'Willians'

Vantagens no uso de Views

1. Você pode usar este resultado em outras consultas diminuindo a complexidade, afinal você fará referência a uma tabela virtual montada fora desta consulta. De uma certa forma podemos considerar como syntax sugar para uma query. Você tem uma visão mais limitada dos dados sem grandes preocupações.
2. Estas consultas pré-definidas ficam armazenadas e você não precisa lembrar de como criá-las. Não confundir com resultados.
3. Como o próprio nome ajuda identificar elas permitem criar uma visão mais lógica para um humano entender a modelagem.
4. Facilita a troca do modelo físico sem o perigo de quebrar queries existentes.
5. Eventualmente o banco de dados pode fazer algumas otimizações por já ter conhecimento das queries utilizadas nas views. Mas normalmente isto depende até mais das estatísticas coletadas.
6. Você pode colocar permissões na view, ou seja, você pode proibir acesso à tabelas em seu estado bruto, mas em uma certa condição o usuário pode ter acesso à informação da forma como você definiu na view. Você controla melhor o que e como o usuário pode acessar a informação. Funciona como um firewall.
7. Regras de negócio podem ser adotadas nas views. A maneira como você vai acessar os dados está pré-definida. Isto é útil para formatar dados, ajudar ferramentas externas e facilitar o acesso via APIs. Pense em colunas computadas. Você pode usá-las como um proxy e realizar operações sempre que os dados sejam acessados.
8. Podem facilitar o acesso em base legada, tornando migrações e transições indolores.
9. Se a view for materializada pode ter ganho de performance para o acesso aos dados já “consolidados”.

Desvantagens no uso de Views

1. Esconde uma complexidade da query podendo enganar o desenvolvedor quanto à performance necessária para acessar determinada informação. E pode ser pior quando views usam outras views. Em alguns casos você pode estar fazendo consultas desnecessárias sem saber de forma muito intensiva.
2. Cria uma camada extra. Mais objetos para administrar. Algumas pessoas consideram isto um aumento de complexidade. Uma outra forma de ver isto é que uma view pode ser mal usada.
3. Pode limitar exageradamente o que o usuário pode acessar impedindo certas tarefas.
4. Se a view for materializada fará com que alterações nas tabelas reais envolvidas sejam mais lentas, afinal são mais tabelas para atualizar. Este tipo de view funciona de forma semelhante a um gatilho.

Existem alguns detalhes técnicos que podem trazer problemas mas acho que não é relevante para esta pergunta.

Diferença para Stored Procedure

Acho que já começa entrar em outra questão. Mas resumindo uma Stored Procedure permite mais flexibilidade para criar algoritmos mais complexos mas ela não cria uma tabela virtual. Como você vai lidar com isto para expor os dados e chamar uma Sproc é um problema do programador dela ou da query que vai usá-la.

LEIA TAMBÉM: 21 comandos SQL essenciais para programadores e BI

Qual a diferença entre view e Materialized view?

View

A view é uma consulta (chega ser um código SQL mesmo) simples armazenada no banco de dados que cria uma ilusão de ser uma tabela, e pode ser usada em diversas operações para:

1. simplificar as queries e facilitar o acesso à determinadas informações
2. conformar melhor com o modelo lógico
3. permitir controlar melhor o acesso aos dados para determinados usuáriosPode-se criar uma view com determinadas colunas e dar permissão de acesso a um usuário ou grupo para essa view, não para a tabela física, aí ele só terá acesso a esses dados.

Todo conjunto de dados da view é gerado no momento que é solicitado (se nenhuma otimização for feita pelo banco de dados). E esse é o único custo, que nem pode ser considerado exatamente de extra porque se está usando ela, provavelmente precisaria fazer isto de qualquer jeito.

Materialized view

Esta é uma view que cria uma tabela auxiliar para armazenar os dados da query estabelecida pela view. Assim o banco de dados cria uma espécie de gatilho automático para que toda atualização de dados nas colunas envolvidas atualize também a visão materializada (tabela auxiliar), permitindo assim o acesso direto aos dados sem maiores processamentos em uma consulta.

1. Com ela você ganha performance de acesso aos dados, mas passa ter um custo maior de atualização dos dados. Precisa analisar o que é mais interessante em cada caso. Então esta é uma otimização de acesso.
2. Ela, obviamente, ocupa espaço em “disco”.

Essas são as principais vantagens e desvantagens dela sobre a view normal.

Fora o fato de haver armazenamento dos dados, elas funcionam de forma essencialmente idênticas (pode variam um pouco dependendo do fornecedor de banco de dados).

É possível simular uma materialized view em todo banco de dados que tenha um mecanismo de trigger.

Referência: https://github.com/maniero/SOpt/blob/master/SQL/Conceptual.md