[firebase-br] Relatorio de View lenta... alguma alternativa?

Gladiston Santana gladiston em vidy.com.br
Qui Nov 29 12:00:33 -03 2018


A idéia de usar procedure,  view ou diretamente a querie não é o seu
problema.
Todas as 3 opções resolvem a questão, mas não o problema, o tempo.

Nobre colega, se você faz uma view, e no seu programa faz um *select from
view where (a=b) and (c>d) and (d<3)*, você desmonta a view, quero dizer,
fica se concentrando na view e esquece que seu programa tá pegando o
resultado de uma view e fazendo um novo where em cima dos resultados. O
plan da view pode estar correto, mas o where externo à ela irá se
concentrar num novo plan que pode tornar obsoleto o anterior.
As vezes é bom não usar a view para que você saiba exatamente o que está
fazendo, que plan o sistema detectou e assim por diante.
Nunca use uma view como modelo de simplificação de querie para facilitar a
vida de programação, eu fiz isso quando aprendi a programar e tostei muitos
neoronios com problemas e puxões de orelha.
Eu gosto de pensar na view mais como uma forma de normatizar o banco. Por
exemplo, alguns meses atrás veio um programador lisp que desejava ter
acesso a tabela de proposta, clientes e produtos para desenvolver seu
programa para autocad, então criei uma view para ele apenas com os campos
que ele precisava e ele pode me dizer até mesmo com que nomes esses campos
deveriam ser chamados.
Então *para mim* uma view não substitui uma querie ou CTE (com o qual um
*select from view where (a>b)* se parece), mas uma forma de normatizar. Mas
não é uma regra, views atualizaveis são bem vindas em alguns contextos.

Se você entendeu a view, vamos para as procedures selecionáveis, precisa
entender que com ela você ganha ou perde tempo dependendo do que pretende
fazer, por exemplo, no seu caso, você faz uso de UNIONS, pense num select
com um where bem generico lendo registro-a-registro e retornando apenas o
que for interessante,  parece ser mais adequado do que usar select com
unions onde voce resolve varios selects e depois faz merge, ponto pra
procedure. Mas imagine uma procedure retornando o que um select resolve,
neste caso é uma situação pior porque na melhor das hipoteses você está de
fato usando uma querie empilhada numa procedure cujo tempo será igual ou
pior.
Mesmo quando uma procedure for a melhor opção, você deve pensar nos
defeitos que podem advir dela, por exemplo, se houver um loop numa
procedure que demora muito para chegar ao fim, o tempo que o loop
persistir, a CPU do servidor vai ficar em 100% (não existe algo como
application.processmessages na linguagem de procedure). Se a versão do FB
for processos separados, não vejo muito problema, mas se for um cache para
todos o tempo de loop poderá ser visto no servidor como 'aplicativo não
está respondendo' por causa do estrangulamento, mas é o funcionamento
normal de qualquer programa que não dê ticks de processo.

Espero não ter embaralhado ainda mais sua cabeça, mas faz parte do jogo,
entender como as coisas funcionam para tomar uma decisão que beneficia o
programa e não o que é mais fácil para você.

[]´s


Em ter, 27 de nov de 2018 às 19:44, SERGIO LOPES <
sergio.comercialgloria em gmail.com> escreveu:

> Boa tarde,
>
> Após aplicar as sugestoes de trocar o operador >= para between, criar
> indices nos campos datas ou modificar a disposicao da lista de tabelas do
> from para o left join ou inner join, não surtiu efeito de redução no tempo
> de execução na view q tem demorado entre 95 a 100 segundos apara exibir os
> dados. Notei que a ideia de usar o procedure pode dar certo para amenizar o
> problema, dado que vou conseguir fazer fitros mais especificos (penso eu)
> enxugando o numero de registro na saida para o minimo possivel. Estou
> fazendo simulaçoes para ver se consigo aplicar exatamente como a view
> funcionava antes... ainda nao tinha feito nenhum procedure dessa
> complexidade, mas, parece esta indo tudo bem ate agora... obrigado a todos.
>
> At.te,
>
> Sergio Lopes



Mais detalhes sobre a lista de discussão lista