Início > banco de dados, programação > Dicas de banco de dados

Dicas de banco de dados

Logo Postgres

Logo Postgres

Estou fazendo um curso de PostgreSQL e meu instrutor tem dado algumas dicas que venho utilizando em situações práticas nas aplicações que desenvolvo para melhorar a performance do banco e diminuir o tempo de retorno das requisições realizadas.

Através de estudos realizados ficou constatado que os problemas mais comuns encontrados em bancos de dados são:

  • 60% relacionados ao mau uso da linguagem SQL;
  • 20% relacionados a má modelagem do banco de dados;
  • 10% relacionados à má configuração do SGDB;
  • 10% relacionados a má configuração do SO.

Seguem algumas dicas que venho utilizando e configurações que podem ser feitas no Postgres para melhorar a interação entre o sistema e o SGBD:

  1. Evite utilizar select * from nome_da_tabela em suas consultas. Por razões óbvias é muito custoso para o banco retornar todas as linhas e todas as colunas de uma tabela quando ela já tem um tamanho razoável e não se tem necessidade de processar todos os dados da tabela;
  2. Sempre utilize INNER JOIN ao invés de utilizar where. SGBD’s como o Postgres e o MySQL não transformam a consulta com produto cartesiano em inner join (já o Oracle o SQL Server transformam), tornando o retorno muito mais lento por conta  de o resultado completo do produto cartesiano ser enviado para a memória para só então o banco realizar a filtragem, enquanto que com inner join só vai para a memória o resultado gerado pelo filtro. Exemplo prático:
  3. Troque:

    select e.* from empregado e, departamento d where d.id_dep=e.id_dep;

    Por:

    select e.* from empregado e inner join departamento d on d.id_dep=e.id_dep;

  4. Utilize UNION ALL ao invés de UNION. O operador UNION primeiro ordena os dados para depois realizar um DISTINCT, tornando o processamento muito mais lento. Dessa forma utilize UNION apenas quando for necessário eliminar possíveis linhas duplicadas;
  5. Utilize DISTINCT com cautela. Da mesma forma que o UNION, o DISTINCT só deverá ser usado quando é necessário eliminar linhas duplicadas, uma vez que para eliminar as duplicidades, ele irá percorrer todo o “Result Set”, o que, dependendo da quantidade de linhas retornadas, pode provocar um grande trabalho extra para o SGBD, diminuindo os recursos disponíveis para os outros processos;
  6. Prefira o EXISTS ao IN. Na grande maioria dos casos a cláusula EXISTS será mais rápida do que IN. Exemplo de utilização do operador EXISTS:
  7. select clientes.nome from clientes where exists (select telefones.clienteid from telefones inner join clientes on telefones.clienteid = clientes.id)

  8. Evite utilizar o tipo inteiro longo (bigint, no Postgres). Além de ser um tipo que consome muito recurso (8 bytes), é mais lento e não tem compatibilidade com todos os sistemas operacionais. O integer consome apenas 4 bytes, tem compatibilidade como todos os S.O.’s e vai de -2.147.483.648  a 2.147.483.648, ou seja, um valor bastante razoável e que, na maioria absoluta dos casos, atende às necessidades dos sistemas;
  9. Evite usar NATURAL JOIN, pois caso se cometa um erro, a consulta pode retornar dados não previstos.
  10. Ao criar functions e procedures no Postgres, utilize SQL puro quando for possível (quando o retorno é resultado de uma consulta e não se tem estruturas condicionais nem laços).  Exemplo:
  11. CREATE FUNCTION selecionarMaiorEstatura(char) RETURNS double precision AS $$
    SELECT max(estatura) FROM atletas WHERE sexo = $1;
    $$ LANGUAGE SQL;

  12. Utilize visões. É um aspecto chave de um bom projeto de banco de dados SQL. As visões permitem encapsular, atrás de interfaces que não mudam, os detalhes da estrutura das tabelas, que podem mudar na medida em que os aplicativos evoluem;
  13. O Postgres pode trabalhar com datas no formato brasileiro (na exibição e nas consultas). Para isso basta entrar no arquivo postgresql.conf, procure datestyle e coloque o valor sql, dmy. Não esqueça de tirar o comentário no início da linha (caractere #).
Anúncios
  1. 19/05/2009 às 04:59

    Algums comentários:
    “select * from …” não retorna todas as linhas, mas todas as colunas de uma linha. Acho que o pior é não colocar nenhuma restrição na consulta, o que retornaria todas as linhas da tabela.

    O “where” deve ser usado sim, mas não para fazer join entre tabelas, e sim para restringir o resultado de acordo com um certo valor de filtro. Nesse caso o join não pode ajudar em nada.

    No exemplo do item 5 você não seguiu a dica do item 2 😉

    Parabéns pelo espírito de compartilhamento. 😉

    • 19/05/2009 às 13:47

      Olá Hildeberto. Bem lembrado. Na verdade, no primeiro exemplo faltou colocar o nome da tabela, para mostrar que o usuário não colocou nenhuma restrição, portanto estava trazendo todas as linhas e todas as colunas dela.

      O exemplo 5 já foi corrigido.

      Abraço e obrigado.

  2. Flavio Soares
    19/05/2009 às 08:59

    Excelente artigo, que orienta muitos desenvolvedores que fazem mal uso do sql. E valiosas dicas para o postgres, pois o setor publico está usando, sem usar a maioria dos recursos fornecidos por este BD.

    Paraben!!!

  3. Marcos Eduardo
    19/05/2009 às 16:22

    Muito bom, deputado. Parabéns pelo post!

  4. 19/05/2009 às 18:33

    Boa deputado, esta de parabéns!

    Boas práticas sempre são bem vindas. Sempre achei importante compartilhar o conhecimento adquirido, principalmente quando podemos utilizar em nosso dia a dia.

  5. 21/04/2010 às 17:30

    legal o post. parabens

  1. No trackbacks yet.

Deixe um comentário

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 )

Foto do Google+

Você está comentando utilizando sua conta Google+. 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 )

w

Conectando a %s

%d blogueiros gostam disto: