SQL – O que são VIEWS SQL, vantagens e desvantagens

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. Claro que o que você vê nesta tabela existe de outra forma no banco. Veja mais detalhes na Wikipedia.

Pode ajudar entender saber que elas também são chamadas de named queries ou stored queries. Não confundir query (consulta) com resultado. Ela é a query mesmo. É basicamente um texto de um SELECT. Pense que ela é uma query que você armazena em uma variável e ao invés de escrever toda a query de novo sempre que for necessária usa a variável. Claro que isto é uma grande simplificação para facilitar o entendimento, o funcionamento real é pouco mais complexo que isto mas não é importante aqui.

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 (resposta aqui).

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 querypara 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.

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:

[sociallocker id=3115][/sociallocker]

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

  • 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.
  • Estas consultas pré-definidas ficam armazenadas e você não precisa lembrar de como criá-las. Não confundir com resultados.
  • Como o próprio nome ajuda identificar elas permitem criar uma visão mais lógica para um humano entender a modelagem.
  • Facilita a troca do modelo físico sem o perigo de quebrar queries existentes.
  • 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.
  • 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.
  • 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.
  • Podem facilitar o acesso em base legada, tornando migrações e transições indolores.
  • Se a view for materializada pode ter ganho de performance para o acesso aos dados já “consolidados”.

Desavantagens

  • Esconde uma complexidade da query podendo enganar o desenvolvedor quanto à performance necessária para acessar determinada informação. E pode ser pior quando viewsusam outras views. Em alguns casos você pode estar fazendo consultas desnecessárias sem saber de forma muito intensiva.
  • 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.
  • Pode limitar exageradamente o que o usuário pode acessar impedindo certas tarefas.
  • 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.

Conclusão

View

view é uma consulta simples armazenada no banco de dados que cria uma ilusão de ser uma tabela, e pode ser usada em diversas operações para:

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

Todo conjunto de dados da view é gerado no momento que é solicitado (se nenhuma otimização for feito pelo banco de dados). E este é 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.

  • 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.
  • Ela, obviamente, ocupa espaço em disco.

Estas 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.

[sociallocker id=1629][/sociallocker]

Ramos de Souza Janones

Janones, é um empreendedor brasileiro apaixonado por empreendedorismo e tecnologia. Ao longo dos anos trabalhando com o desenvolvimento de softwares desktop desde a linguagem Clipper, passando pelo Delphi e atualmente com Java.

Optou pela formação de Publicidade e Marketing por sua segunda empresa de tecnologia ter participado do "boom" da internet nos anos 90 e na procura de melhorar seus conhecimentos em negócios.

Em razão da principal formação e profundos conhecimentos em programação e banco de dados, é capaz de realizar o desenvolvimento de aplicativos web, desktop e mobile com maior criatividade e inovação que profissionais de desenvolvimento com uma formação única e mais especifica, dedicada somente ao desenvolvimento de softwares.

Com toda sua experiência com empresas de software, sua formação e paixão por negócios escreveu o livro "Marketing para Empresas e Profissionais de Software", publicado pela editora carioca Ciência Moderna em 2012. Além de outros livros sobre programação.

Últimos posts por Ramos de Souza Janones (exibir todos)

Share this post

scroll to top