.png)
Fala pessoal, dessa vez o tema é desenvolvimento de objetos no banco de dados.
Views, functions e procedures nos dão um grande leque de possibilidades. Vamos tratar nesse post sobre as views.
Desenvolver uma view não é simplesmente pegar aquele comando que sempre executa e encapsular o mesmo dentro da view.
É necessário avaliar algumas situações para que esse objeto não venha a causar problemas de performance no banco de dados.
Aqui vão alguns pontos a considerar:
1) Nunca utilize o " * " - as views na maioria das vezes são criadas com JOINs, retornar todas as colunas de todas as tabelas nunca é uma boa opção. Além de deixar a query bem lenta, o consumo de memória será muito alto.
2) Monte a sequência dos JOINs de forma que a sua tabela "principal" seja a primeira - a ordem errada das tabelas e relacionamentos das mesmas faz com que o tempo de retorno da query também seja alto. Por exemplo: Tabela de pedidos e tabela de clientes, o intuito é retornar todos os pedidos e o nome dos clientes, nesse caso, a tabela pedido deve vir primeiro no JOIN.
3) Evite JOINs de tabelas com outras views dentro da que esta desenvolvendo - a utilização de views em camadas também torna a query mais demorada.Além disso o otimizador de consulta não tem como estimar o que a view "interna" vai utilizar de recurso e nem quantas linhas irá retornar pois os valores serão descobertos apenas em tempo de execução.
4) Filtre a view - por mais que os parâmetros de filtro sejam passados pela aplicação ou relatório, sempre que possível fixe algum filtro internamente na view. Se estivermos falando de uma view para o setor de contabilidade por exemplo, dificilmente o usuário irá precisar analisar dados de 2 anos atrás. Nesse caso, deve-se filtrar internamente para que a view retorne apenas o último ano de informações e então a aplicação trata de filtrar esses dados com mais alguns filtros.
5) Limitar o número de registros - Uma boa prática também é limitar o número máximo de linhas que a view irá retornar. Em uma situação em que o usuário filtrou errado por exemplo, o limite a retornar não permitiria que a view gerasse algum problema de desempenho no banco.
6) Mudar subselects para CTE - muitos subselects também podem diminuir a performance da query como um todo, sempre que possível altere para CTE (você pode ver mais sobre CTE nesse link: aqui)
Importante considerar também até que ponto usar uma view é melhor do que partir para uma procedure. Em algumas situações (onde trabalhamos com muitos registros) passar um filtro de data para a view não é tão performático como passar um filtro para uma procedure. Levando em conta que a view primeiro executa o seu conteúdo (ou seja, o select completo nas tabelas) e somente depois desse resultado aplica o filtro de data informado, se usarmos uma procedure que recebe como parâmetro o período de datas e internamente aplica o filtro no select principal, estaríamos fazendo o "corte" das informações direto na fonte, o que retorna menos informação, consome menos recurso e obviamente retorna mais rápido.
View é um excelente recurso, se bem utilizada, claro!
Até a próxima!