Série da semana: Primeiros passos no React

Veja mais

Consultas demoradas: banco ou Delphi?

30/11/2015

1

Consultas demoradas podem ser apresentadas de diversas formas(as mais comumente conhecidas), como detectar esses problemas no banco de dados ou na propria tecnologia(Delphi)?
Responder

Post mais votado

01/02/2016

Você pode criar views, uma boa estruturada no select ajuda bastante.

Carregando apenas campos necessários [ Ao invés do select * from] .

Lembro que tinha uma tela de recebimento de mercadorias, com o passar do tempo, o setor esperava cerca de 8 a 10 minutos.

Ao estruturar bem a consulta e criação de views conseguir reduzir o retorno para rum time.

Só para complementar o servidor deve está em perfeito estado de processamento de dados.
Rede estruturada.
Responder

Mais Posts

01/12/2015

Marcos P

Mantendo as estatísticas do lado do banco de dados atualizadas, você consegue definir o custo de cada query, otimizando-as.

Feito isso, tudo que sobra é problema de infraestrutura ( rede, por exemplo ) ou da arquitetura da aplicação.

Em outras palavras, otimize as queries para que elas tenham a melhor performance possível no ambiente nativo do banco de dados e, depois, olhe seu ambiente de desenvolvimento !
Responder
Não tinha pensado na rede, verdade.
Responder
Isso é tudo que pode está relacionado aos possiveis problemas de lentidão? Se sim, muito obrigado.
Responder
Isso é tudo que pode está relacionado aos possiveis problemas de lentidão? Se sim, muito obrigado.


???
Responder
Isso é tudo que pode está relacionado aos possiveis problemas de lentidão? Se sim, muito obrigado.


???
Responder

01/02/2016

Ronaldo Filho

Grande, bom dia.

Uma coisa que causa muita lentidão é o fato do pessoal trabalhar com acesso direto ao banco de dados, sem o uso de dataSet's em memória, é difícil para o programador esperar velocidade se o tratamento das operações com o banco de dados ocorrem com ele ainda conectado ao banco, o que se fala muito hoje é da informação tratada sem que a conexão com o banco permaneça ativa, ou seja, a conexão com o banco ela é feita apenas quando você vai pegar e salvar a informação, fechando-a logo após receber ou salvar a informação. O que é muito comum no Delphi é, o programador através de uma query, por exemplo, abre a conexão com o banco e mesmo recebendo o resultado permanece com ela ativa, fechando apenas quando finaliza a tela, nesse momento devemos imaginar, apenas uma máquina utilizando o sistema não vai trazer tanta lentidão, mas quando você tiver 15 máquinas usadas ao mesmo tempo, com conexões ativas, vai ocorrer lentidão, por que serão 15 instâncias de conexões usando memória, processador, entre outros recursos, sem contar que o servidor do banco de dados estará sobre carregado tendo que segurar 15 conexões com o banco, mesmo que elas não estejam coordenando dados.

No caso a orientação que posso deixar aqui é, utilize o que você poder para que, ao utilizar a conexão com o banco deixe ela ativa apenas no momento que precise coletar dados ou salvar, assim que obtiver os dados ou o retorno da operação que estava realizando, encerre a conexão, pois assim você terá as informações que precisava e não estará congestionando a comunicação com o banco. Conectar apenas quando for realmente necessário.

Outras coisas são, evitar salvar dados nulos em tabelas, realizar selects com subselects, muitos joins numa mesma consulta ou unions, ter cuidado também ao criar views, por que também essas estruturas pré-definadas podem acarretar problemas se feitas de maneira a carregar muita informação de uma vez, em listagens podemos dividir a quantidade de informação a ser listada e conforme for sendo necessário poderemos carregar mais informação, essa informação pode ser carregada em blocos pequenos a fim de melhorar mais a performance das operações.

Deve-se notar que, ao desenvolver aplicações para usos específicos, você deve realmente se preocupar com os dispositivos que irão executar a tua aplicação. Você deve se preocupar com o uso de memória, processamento, rede, entre outros fatores que irão fazer jus a um maior ganho de desempenho, muita gente fala sobre começar a trabalhar com escalonamento de memória, mas devemos lembrar que hoje as linguagens e os padrões de desenvolvimento já trabalhando essa parte para você, então você deve se preocupar mais com a questão dos termos de sua aplicação quanto ao uso de memória (sem se preocupar com o escalonamento), processamento (trabalhar bem o estado ocioso de sua aplicação) muitas linguagens oferecem uma gama bem vasta de recursos para controle de processamento em status ocioso, uso da rede (conexões em rede apenas em momentos necessários à aplicação), entre outros.

Bom grande ficam ai algumas dicas para refletir. Tudo inicia com as escolhas de tecnologias e métodos, até a forma como você vai resolver o problema proposta para a construção da aplicação.
Responder
P2 e Ronaldo só tenho que agradecer pela qualidade e cuidado com as informações.
Responder

01/02/2016

Ronaldo Filho

Grande, nós agradecemos também, pois esses debates trazem valor à nossa área, e ajudam na obtenção e divulgação de conhecimento. E fique sempre disposto a voltar aqui e expor suas dúvidas pois existem vários como nós que estão sempre dispostos a ajudar.
Responder
Sem que puder e tiver duvidas não pensarei duas vezes.
Responder