Início > DB2 / Banco de dados > Boas práticas em SQL para desenvolvedores

Boas práticas em SQL para desenvolvedores

Boas práticas em SQL para desenvolvedoresQuem 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.

  1. Arauca
    janeiro 6, 2008 às 2:28 pm

    Um bom artigo.

    Não tenho muita experiência em banco de dados, pra falar a verdade quase nada =P
    Estou encarregado de criar um pequeno DB pra fazer cadastro. Algo que vai ser usado intensamente por cerca de duas semanas, e que dpois deve listar as tabelas ordenadas pra fazer a repartição dos grupos de alunos.

    Tenho buscado aprender sobre o assunto, e seu artigo é bem interessante.

    Pra quem quer conhecer um pouco mais, recomendo o curso de MySQL e Linguagem SQL do CDTC – http://comunidade.cdtc.org.br/

  2. janeiro 6, 2008 às 10:30 pm

    Oi Arauca.

    Eu dei uma olhada, realmente muito bom!

    Abraços

  3. Jean Cabral
    janeiro 16, 2008 às 2:39 pm

    Olá Juliano,

    Parabéns pelo artigo. Muito bom.

  4. Renato Godinho
    março 10, 2009 às 1:19 pm

    excelente Juliano!!!
    mto bem escrito!
    gostaria de dividir com os colegas de faculdade, citando seu blog, claro, se vc permitir !

    abs

  5. julho 2, 2009 às 5:56 pm

    Juliano, parabéns pelo blog.

    Mantenho um blog sobre T-SQL (http://www.tsqlmaster.net/) e gostaria de referenciar este seu artigo em um novo post. Sem problemas?

  6. Anonimo
    agosto 9, 2009 às 9:16 pm

    É exatamente isto que eu procurava, umas dicas de desenvolver um sistema com boas praticas no SQL e vc me ajudou das dicas. Fiz estagio de desenvolvimento e posso confirmar suas dicas. Os “MESTRES” usam frequentemente o “select * from” no seu ERP, e eles tem reclamações de usuarios do sistema quanto a performance. São pequenas coisas que fazem a diferença. Ótimo Texto.

    abraços

  7. Divino Sérgio Mendes
    julho 16, 2010 às 2:00 pm

    Oi Juliano,

    Muito bom seu artigo esta me ajudando muito.

    Tenho uma duvida enorme. Aqui temos tabela com chave primaria compostas, exemplo: cod_funcionario, emp_funcionario.

    Seria correto usar assim, ou seria melhor criar um chave primaria única e sequencial (tabela_id), e depois criar índice único com os campos cod_funcionario, emp_funcionario.

    Vejo na última opção um forma mais fácil para criação de relacionamento usando assim só a chave primaria.
    Ao contrario teria que criar os dois campos na tabela que receberia o relacionamento.

    Como tudo aqui esta vinculado a uma empresa (dados multi-empresa), imagina uma tabela filha recebendo o relacionamento de seus pais.
    Tenho aqui uma tabela que possui cinco campos de empresa.

    Me ajude a convencer minha equipe a mudar este conceito, ou se estiver correto me convença, por favor.

    Obrigado.

  8. Diego Martins
    fevereiro 3, 2011 às 4:20 pm

    Valiosas dicas. É sempre bom ter cada vez mais informações a respeito de instruções SQL, pois elas impactam, muito mais do que imaginam, na aplicação.

    Valeu!

  9. Giulio Falcão
    agosto 31, 2016 às 2:50 pm

    Boa tarde.

    Muito bom artigo, sou experiente em Banco de Dados e SQL.
    Uma dica de reforçço : Utilize o campo Like, apenas se o seu SGBD não possuir a clausula REGEXP.
    Evite refazer codigos identicos, crie Views.

  1. No trackbacks yet.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: