Práticas de otimização em Banco de Dados

Saudações, leitores!
Bom, já sabemos que uma aplicação não é feita somente de códigos-fonte bem estruturados. Devemos também nos importar com as instruções SQL que executamos no banco de dados, evitando o consumo desnecessário de processamento. De nada adianta ter uma aplicação com visual elegante e boas funcionalidades se houver lentidão para gravar ou consultar informações no banco de dados.

Introdução

Em poucas palavras, um banco de dados é uma coleção de informações de forma estruturada com a finalidade de armazenar dados sobre um determinado assunto. Como desenvolvedores, devemos manipular esses dados de forma otimizada para colaborar com o desempenho da aplicação.

Bom, considerando que você, leitor, já detém conhecimento em linguagem SQL, esse artigo aborda basicamente algumas práticas especificamente voltadas para ambientes onde há conexões simultâneas no banco de dados, ou seja, softwares de médio a grande porte. Logo, a maioria delas não surtem grandes diferenças em softwares de pequeno porte que possuem quantidade relativamente pequena de dados. Na verdade, são pequenos “ajustes” que, quando feitos em massa, podem trazer melhores performances nas respostas de consultas SQL. Caso você tenha alguma sugestão, não hesite em deixar um comentário, ok?

Evite o asterisco

Em uma instrução SELECT, evite adicionar o asterisco para selecionar todas as colunas. Quando você o usa, o banco de dados precisa interpretar o asterisco como a junção de todas as colunas da tabela, realizando uma espécie de conversão. Além do mais, dificilmente é preciso selecionar TODAS as colunas de uma tabela, ao menos que seja realmente necessário.

Cuidado com o DISTINCT

O comando DISTINCT tem a função de apresentar as ocorrências distintas de um campo em todos registros selecionados na tabela. A questão é que o banco de dados precisa realizar uma série de operações para aplicar um DISTINCT:

• Selecionar os registros
• Comparar os registros que tem valores iguais e ignorá-los
• Comparar os registros que tem valores diferentes e selecioná-los
• Construir o resultado utilizando as comparações acima

Em uma tabela com muitos registros, o DISTINCT pode exigir grande processamento do banco de dados. Quando for utilizá-lo, certifique-se de adicionar condições na cláusula where para que o processamento seja realizado no mínimo de registros possível.

A desvantagem do ORDER BY

A ordenação de registros de uma tabela é um recurso importante, mas também deve ser utilizada com cautela. Considere uma tabela com milhares de registros e a seguinte instrução SQL:

Ao rodar essa instrução, o banco de dados terá que ler todos os nomes dos clientes da tabela e classificá-los em ordem alfabética para exibi-los no resultado. Essa ordenação pode demorar um bom tempo e afetar o desempenho do banco de dados.

A sugestão é efetuar essa ordenação na aplicação cliente em um conjunto de dados. No Delphi, pode-se utilizar a propriedade IndexFieldNames de um DataSet para realizar a ordenação em memória. Em uma arquitetura do tipo Cliente/Servidor, ordenar os registros na aplicação cliente pode reduzir a carga de processamento no banco de dados.

Joins em excesso

Muitas vezes precisamos fazer ligações entre tabelas em uma instrução SQL para obter valores relacionados, normalmente realizadas através de chaves estrangeiras utilizando a cláusula Join. Porém, Joins em excesso podem comprometer o desempenho da consulta, uma vez que o banco de dados irá traçar todo um plano de execução para associar todas as tabelas. Para cada Join, o banco de dados precisa “armazenar” a informação das chaves do relacionamento para garantir o retorno esperado.

Já encontrei casos onde era praticamente inviável obter um valor de uma tabela por causa do longo plano de Joins que a instrução percorria até encontrá-lo. A solução foi criar uma tabela adicional para reduzir a “distância” entre as tabelas, e, consequentemente, reduzir a quantidade de Joins.

Valores totais devem ser gravados ou calculados?

Esse assunto é bastante discutido entre desenvolvedores e DBAs. Em uma tela de venda, imagine que para adicionar um item da venda é preciso digitar a quantidade e o preço unitário. Por exemplo:

E então surge a questão: O valor total de 100,00 deve ser gravado em uma coluna na tabela ou gravar somente a quantidade e o preço unitário já é o suficiente para calcular o total?
Bom, para gravar o valor total na tabela é necessário criar mais um campo, no entanto, facilitará consultas SQL, já que será necessário apenas incluir essa coluna na instrução SELECT.

Se o desenvolvedor optar por gravar somente a quantidade e o preço unitário, deve estar ciente de que, ao consultar vários itens, a multiplicação da quantidade pelo preço para calcular o total será feita para cada registro selecionado, e em seguida, para calcular o total da venda será necessário somar todos os valores totais dos itens.

Essa questão é relativa para cada tipo de sistema. Cabe ao responsável pelo desenvolvimento analisar a melhor opção para o projeto.

Embora sejam dicas rápidas, procure adquirir o hábito de praticá-las quando trabalhar com banco de dados, ok?
Fico por aqui, leitores:

Até a próxima!