Quem nunca ouviu alguem reclamar: “o sistema está lento hoje!!!”? Nestes relatos de degradação de desempenho, frequentemente levantamos que esta degradação é decorrente de instruções SQL mal estruturadas ou ainda banco de dados mal planejado, o que, num efeito cascata, só é sentido conforme o sistema vai sendo utilizado, as tabelas sendo povoadas, etc. O SGDB começa a exigir muito processamento, memória e a gerar gargalos na rede, causando assim, efeitos no desempenho da aplicação e na rede!
Outro fato é que atualmente, boa parte dos desenvolvedores desenvolvem código SQL sem ter muito conhecimento sobre fundamentos de banco de dados. Tal falta de conhecimento gera a produção de código ineficiente e com baixa performance. É comum ver equipes de desenvolvimento que não tem um DBA, ficando assim, o desenvolvedor com a tarefa de criar um banco de dados.
Com estes problemas em mente, resolvi criar este post com algumas dicas para que os desenvolvedores tenham algum conteúdo básico e rápido e melhorem suas instruções SQL e a criação de banco de dados.
Tentarei ser o mais genérico possível para conseguir cobrir os bancos de dados mais utilizados atualmente (DB2, Oracle, MySql, Postgres, etc), porém, algumas dicas podem não ser aplicáveis a todos os bancos.
É importante lembrar que praticamente todas as dicas são “debatíveis” em diferentes cenários, portanto, fiquem a vontade para comentar.
Vamos lá:
1- Normalize seu banco de dados. Isso quer dizer básicamente, divida tabelas grandes em tabelas menores e remova redundancia, ou seja, que dados estejam duplicados sem real necessidade.
2. Em instruções select, evite usar “*”. Seja restritivo, traga somente os campos realmente necessários, isso alivia a memória do servidor, diminue tráfego na rede, etc. Algumas pessoas defendem que tambem não devem ser criados determinados campos, por exemplo, você tem A + B e pretende guardar C onde C = A + B. Ao invéz de criar uma coluna para armazenar C, passe a utilizar “select (A+B) AS C from tabela”. Esse pensamento pode não ser necessariamente válido para Dws. Vamos supor que você tem uma tabela enorme com dados sobre salário por ano. Você pode armazenar o percentual de ajuste e o valor ajustado, fazendo ai uma “desnormalização” para que o comando que vai recuperar os valores do salário não “frite” a CPU forçando-a a fazer muitas contas e perdendo muito desempenho.
3. Existe muito debate sobre essa: Não utilize seu banco de dados para armazenar imagens, ao invéz disso, armazene a URL. Vale lembrar que os bancos de dados atuais estão cada vez mais aprimorados na manipulação de imagens, portanto, aqui abre-se espaço para uma enorme discussão, benchmarck, etc.
4. Para obter maior performance, utilize chaves primárias numéricas ou ainda campos pequenos nas chaves.
5. Utilizando-se stored procedures e functions ao invéz de escrever código no seu programa, vai garantir maior desempenho e segurança para seu sistema como um todo.
6. Utilize o conceito de transações. Vários problemas podem ocorer, por exemplo, a rede cair. Aprenda sobre commit e rollback.
7. Use sempre o tipo de dados correto para armazenar os dados. Por exemplo, não armazene sexo, que vai ser M ou F em um campo Varchar, use apenas 1 caractere: CHAR(1).
8. Evite o uso de cursores, eles consomem muito tempo já que “navegam” registro por registro.
9. Otimize a clausula WHERE: Simples exemplos são o uso de “>” e “>=”. Se você quer retornar todas as pessoas de uma tabela que tem idade “> 3”, use no where “>=4”, dessa forma o banco não fará o scan das páginas até encontrar o 3. Esse princípio é válido desde que você tenha um índice na idade.
10. Quando possivel, crie instruções SQL idênticas, pois no momento da execução de uma instrução, o banco compila a mesma e a preserva em memória, na próxima execução, não vai precisar compilar novamente. Uma ótima técnica para fazer isso é utilizar variáveis nas suas instruções ao invés de passar parametros para o banco.
11. Utilize os mecanismos do banco de dados para persistência: Primary Key, Foreign Key, etc são feitos e otimizados para isso.
12. Quando possivel, trave (lock) uma tabela para executar alguma operação que vai demandar muito acesso a esta tabela, por exemplo, se você vai alterar a estrutura de uma tabela grande ou importar dados neste tabela (falando-se de tabelas realmente grandes).
13. Sempre utilize o nome das colunas em instruções SELECT, INSERT, UPDATE evitando utilizar “*”.
14. Evite utilizar o operador “LIKE”, ele pode facilmente fazer o desempenho de um banco de dados ruir!
15- Utilize EXISTS ao invéz de COUNT para verificar se existe um determinado registro em uma tabela. É comum ver desenvolvedores fazendo um “select count(X) from Y” para verificar se o COUNT é maior que 0. Utilizando-se EXISTS, o sgbd vai parar no primeiro registro encontrado, se utilizar count, o banco vai varrer toda a tabela.
16- Em joins de tipos de dados diferentes, o SGBD vai ter que converter o tipo hierarquicamente inferior para o outro tipo a fim de efetuar a comparação, e assim, não vai utilizar um índice caso exista.
17. Sobre índices:
- Não crie indices em campos que são alterados constantemente, pois o banco vai ter que atualizar toda sua estrutura de índices em qualquer update feito no campo.
- Prefira criar os indices em chaves primárias e estrangeiras, e em suas queries, utilize estes índices.
- Não tenha muitos índices em seu banco, só o necessário: uma breve explicação sobre o motivo disso, é que o banco de dados mantem toda uma estrutura para gerenciar os índices, então, quanto mais índices, mais tempo/processamento o SGBD vai utilizar para a manutenção dos mesmos.
- No momento de importação/importação de uma base de dados, não exporte/importe índices. Isso vai consumir mais tempo/processamento. Tambem pode-se não fazer backup de índices.
- Não crie índices em colunas que possuem pouca variação de valores.
18. Entenda os fundamentos de banco de dados. Uma ótima leitura é o livro “Sistema de Banco de Dados”, de Abraham Silberschatz, Henry F. Korth e S. Sudarshan lançado no Brasil pela Editora Elsevier.
Recomendo aos desenvolvedores de plantão darem uma olhada no software DBJMIN do meu amigo José Damico. DBJMIN é um cliente de multiplos bancos de dados inspirado no phpMyAdmin.
O Primeiro IBM Tutorial Day foi realizado na 
O Banco de Dados DB2 versão 9 para Linux, Unix e Microsoft Windows foi anunciado como revolucionário por razão da sua capacidade de trabalhar com XML nativamente. Por se tratar de um produto relativamente novo, há na literatura disponível poucos estudos que abordem de maneira objetiva e prática suas características em relação ao XML. Portanto, escrevi um artigo em conjunto com o professor Dr. Alex Poleto, da FEMA-ASSIS, que apresenta as características e funcionalidades do DB2 e demonstra o uso do mesmo em um cenário definido, com a intenção de contribuir com a comunidade acadêmica e profissional gerando um material de consulta que poderá servir de base para novos estudos.
