Não use views até saber disso!

Banco de Dados
#1

Vídeo muito bom sobre uso de views

4 Curtidas
#2

Já cheguei a fazer um estudo sério a respeito e daria pano para manga entrar numa discussão a respeito.

Infelizmente para sqls complexos a app de grid do SC rejeita, por causa da reconstrução do SQL que o SC realiza.

Já fiz trabalhos de ganho de performances só reestruturando views.

Mas já comparei rodar o sql complexo e a view com o mesmo SQL a performance é exatamente a mesma.

Numa consultoria para melhorar a facilidade em um projeto, o cliente ficava adicionando campos e joins para usar a mesma view em consultas distintas.

Outra coisa, a preguiça do programador em usar os campos necessarios, acabava usando Select * from tabela join tabela 2 com cláusulas where dentro da view. Isso detona a performance.

Cada view tem que ser construida especificamente para cada consulta.

O select final deve estar em apenas uma view, ou seja, nunca usar select campo from view inner
Join view2 where campo < (select campo from view3 where campo = campo)

Por incrível que pareça peguei esse tipo de código.

Resumindo, usar apenas quando for estritamente necessário e montar querys dentro da view que atendam especificamente a necessidade da consulta em questão.

7 Curtidas
#3

Obrigado por compartilhar sua experiência.

1 Curtida
#4

Parabéns Mestre.
Fiz testes parecidos e também vi a mesma coisa.
Eu acho que vale a pena usar views, desde que bem feitas e indexadas, como você falou.

Erro ao compilar após excluir a cláusula WHERE de uma grid
#5

Outra coisa que não foi dito no vídeo é que a VIEW provavelmente trará TODOS os dados para só depois aplicar o filtro que você escolheu.
Então ao chamar uma view, o banco de dados trará todos os registros daquela view e depois executará o filtro.
Funciona mas perdemos um pouco em performance. Para banco de dados gigantes, na casa de milhões de registros, haverá um impacto significativo.

#6

Desculpa, mas pelos meus testes não é isso que acontece.

1 Curtida
#7

Se a view usar funções agregada isto realmente ocorre.
Em funções agregadas é criado uma tabela temporária com o resultado da query. Então a função agregada irá ser aplicada nesta tabela temporária.
Tudo de forma automática sem a gente perceber.
É interessante notar que dependendo de algumas variáveis setadas no my.cnf ele irá tentar criar a tabela temporária em memória. Se exceder o limite destas variáveis ele criará no disco.
Então resultados de views que ultrapassem este limite serão escritas em disco.
Num sistema de alta concorrência e que consultem muitas views com esta características terão que ter disco com valores de IOPS maiores.
Um banco pequeno com algumas tabelas de 5GB a 10GB não irá sofrer tanto. Mas comece a pegar tabelas acima de, por exemplo, 100GB e irá notar a lentidão para views que trazem muitos dados.

Para entender melhor:
https://dev.mysql.com/doc/refman/8.4/en/internal-temporary-tables.html

2 Curtidas
#8

Complementando:

Sim, as funções agregadas em views SQL podem gerar tabelas temporárias com os dados resultantes, mas isso depende do banco de dados específico e da implementação da view. Aqui estão alguns detalhes:

Comportamento dos Principais Bancos de Dados

  1. SQL Server: As views são armazenadas como consultas, não como tabelas físicas. Os dados são calculados em tempo de execução.
  2. MySQL: As views são armazenadas como consultas, mas podem ser armazenadas em cache.
  3. PostgreSQL: As views são armazenadas como consultas, mas podem ser materializadas (armazenadas físicamente) usando a cláusula “MATERIALIZED VIEW”.
  4. Oracle: As views são armazenadas como consultas, mas podem ser armazenadas em cache.

Características das Tabelas Temporárias

  1. São criadas automaticamente pelo banco de dados.
  2. São armazenadas em memória (RAM) ou em disco.
  3. São eliminadas após a execução da consulta.
  4. Não são visíveis fora da sessão atual.

Otimização de Desempenho

  1. Utilize índices adequados nas colunas utilizadas nas funções agregadas.
  2. Evite usar funções agregadas em colunas com muitos dados.
  3. Utilize a cláusula “LIMIT” para reduzir a quantidade de dados.
  4. Considere utilizar tabelas temporárias explícitas para melhorar o desempenho.

Exemplo de Materialized View em PostgreSQL

CREATE MATERIALIZED VIEW vendas_por_regiao AS
SELECT 
  regiao, 
  SUM(valor_venda) AS total_vendas
FROM 
  tabela_vendas
GROUP BY 
  regiao;

Para atualizar a view materializada:

REFRESH MATERIALIZED VIEW vendas_por_regiao;
1 Curtida
#9

Ótima explicação…

1 Curtida