Pesquisar

Quem sou eu

Minha foto
Formado em Tecnologia de Processamento de Dados pela FESP-Paraná. Pós-graduado em Administração em Informática e Administração de Banco de Dados pela FESP-Paraná. Certificação ORACLE/OCA e DB2 9 Family Fundamentals.
Mostrando postagens com marcador PERFORMANCE. Mostrar todas as postagens
Mostrando postagens com marcador PERFORMANCE. Mostrar todas as postagens

domingo, 17 de junho de 2012

DICAS PARA PROGRAMADORES SQL

Olá!

Após um LONGO período sem postagens, estou de volta.

Durante este período, fiquei a maior parte do tempo focado em algumas atividades de Tuning de SQLs. Decepcionei-me e cheguei a conclusão de que, infelizmente ou felizmente (para noooosaaa alegria ... hehehe), a maioria dos programadores possuem uma certa deficiência técnica, quando o assunto é escrita de um código SQL eficiente. Em vários casos, me deparei com alguns erros "bobos" tais como:

uso excessivo, e na maioria das vezes desnecessário da cláusula DISTINCT - pessoal, o DISTINCT implica em operação de SORT de linhas e todos nós sabemos que SORT custa caro. Portanto, procure utilizá-los somente quando realmente necessário;

joins incorretos entre as tabelas - este é um item básico quando o assunto é boa escrita e performance, mas por incrível que pareça, é muito comum encontrar erros. A dica é simples e até batida já, mas funciona e muito para evitar erros: para N tabelas na cláusula FROM deve haver N-1 JOINS de tabelas. Outro ponto fundamental a ser observado neste item é que, se você precisa unir muitas tabelas para buscar uma determinada informação, talvez seja a hora de parar e solicitar ao DBA uma ajuda na revisão de seu modelo de dados, pois com certeza ela não está com um desenho adequado;

uso desnecessário de UNION - verifique se seu UNION não pode ser trocado por um OR ou CASE ... WHEN ... THEN. Na maioria das vezes, o UNION pode ser substituído por estes comandos gerando apenas uma única query;

uso de * quando na verdade, apenas 1 ou 2 campos dos 30 de uma tabela, eram necessários no comando SELECT - adote a boa prática de colocar, SEMPRE, apenas os campos necessários na cláusula SELECT. Evite o uso de *;

uso excessivo de subquerys na cláusula SELECT - cuidado com o uso de subquerys na cláusula SELECT. Além de seus custos não aparecerem no plano de acesso, na maioria das vezes, a performance é bem melhor quando estas subquerys são colocadas na cláusula FROM;

gravar vários atributos concatenados em um único campo - procure gravar cada dado em seu próprio campo. Separe cada atributo. Muitas vezes, grava-se vários em uma mesma coluna do banco de dados e depois aota-se a função SUBSTR sobre o campo para separar as informações. Esta prática inibe o otimizador ORACLE de utilizar qualquer índice sobre a coluna.

Esperam que tenham curtido as dicas pessoal. Se lembrar de mais algumas, postarei em futuros artigos.

Saudações.