Boas práticas SQL

Boa noite pessoal.

Ultimamente ando me preocupando um pouco mais com banco de dados do que antes. Nos sistemas que estou desenvolvendo e os que ja desenvolvi, todos usavam mysql, mas agora decidi que quero sair dessa mesmisse... peguei um banco de cep no mysql e migrei para o postgresql, a diferenca de performance foi absurda... Depois de muito testar e comparar os dois bancos, decidi que quero usar postgre. Deixando o desabafo para lá... tenho uma dúvida sobre sql, mais especificamente com selects, quando preciso fazer uma select em que desejo pegar todos os campos, uso SELECT * FROM... Já ouvi dizer que isso é uma péssima prática e que usar AS para dar nome às colunas do resultset é uma boa. Entre uma e outras dúvidas do tipo, resolvi postar para ver se além dessas, possa existir (com certeza existe) outros conselhos.

Obs: Falando de desenvolvimento desktop...

Obrigado pela atenção de todos.

Este artigo tem uma lista de algumas http://jmmwrite.wordpress.com/2007/12/19/boas-praticas-em-sql-para-desenvolvedores/. Só adiciono que em Java sempre utilize Prepare Statement, nunca a SQL diretamente.

Att.

Então... eu tinha passado por ai antes de postar. Por que você usa prepareStatment em vez de createStatment? Segundo o artigo, compor a sql é melhor por que o sgbd memoriza o processo e a segunda consulta fica mais rápida se for a mesma.

Neste caso prefiro usar PreparedStatement, pois é mais fácil de manter. No caso de ficar mais rápido, acho que não fica. Independentemente da forma com que o SQL foi construído, quando este chegar ao banco será o mesmo. Assim, de qualquer forma, se houver cache de operações anteriores o SGBD o utilizará.

Att.

Olá, já que voce esta querendo aprofundar mais com banco de dados, de uma olhada no hibernate, framework para persistência. http://www.hibernate.org/

Virtual Machine Man Membro desde: 04/08/2010 09:37:57 Mensagens: 543 Offline

Adelar wrote:Neste caso prefiro usar PreparedStatement, pois é mais fácil de manter. No caso de ficar mais rápido, acho que não fica. Independentemente da forma com que o SQL foi construído, quando este chegar ao banco será o mesmo. Assim, de qualquer forma, se houver cache de operações anteriores o SGBD o utilizará.

Att.

Na verdade fica mais rápido sim... com o prepared (além de mais segurança) você evita um novo hard-parsing pois o banco provavelmente terá em cache sua query...

=gqferreira wrote:Então... eu tinha passado por ai antes de postar. Por que você usa prepareStatment em vez de createStatment? Segundo o artigo, compor a sql é melhor por que o sgbd memoriza o processo e a segunda consulta fica mais rápida se for a mesma.

veja bem essas duas queries:

para o banco de dados, são duas queries diferentes, portanto no cache vai ter uma versão de cada... com prepared ficaria:

daí o banco faria cache, independente do valor....

JavaChild Membro desde: 09/04/2008 17:35:24 Mensagens: 129 Offline

Muito legal.. então... Por isso o hibernate utiliza prepared.

E com a opção show_sql = true. ele mostra todas as consultas com ?.

Isso faz com que uma liste utilizando esses modelo, fique muito mais rápido o seu retorno.

Legal Obrigado.

Pois é, o hibernate tem muitas otimizações prontas, o que facilita muito na hora de desenvolver e manter depois os bancos.

Att.

Legal, o clima está bem didático...

Vocês acham que compensaria implantar o hibernate em um ERP na metade do desenvolvimento?

Eu sei mais ou menos o que faz o hibernate mas nunca usei e precisaria aprender como ele funciona.

Mas se nao usar o hibernate, vou ver se troco o createstatment pelo prepared...

gqferreira wrote:Vocês acham que compensaria implantar o hibernate em um ERP na metade do desenvolvimento?

Não arrisco dizer se compensa... segue uma lista do que tem que considerar:
- Como o sistema está desenvolvido. Se estiverem sendo utilizados Pojos para a passagem para a camada de persitência facilita
- Tamanho e complexidade das regras de negócio do sistema
- Conhecimento da equipe sobre a tecnologia e principalmente como adaptá-la os esquemas dos bancos utilizados
- e outras...

Att.

Bom, minha camada de persistencia está separada. A complexidade do sistema ainda não está tao dificil mas a equipe (eu sou a equipe do projeto

) nao tem conhecimento de hibernate.

gqferreira wrote:Bom, minha camada de persistencia está separada. A complexidade do sistema ainda não está tao dificil mas a equipe (eu sou a equipe do projeto ) nao tem conhecimento de hibernate.

Por estar em uma camada separada facilitar o trabalho. O melhor é fazer alguns testes para ver se o esquema do banco se adapta bem ao hibernate. O principal problema não é aprendê-lo, mas conseguir se adaptar... nada que uma boa dose de persistência não passe

Att.

Obrigado Adelar, estou estudando Hibernate e estou conseguindo adaptar, mas e a questao do "SELECT * " ? Considerando que realmente precisarei de todos os campos, ainda sim é aconselhavel discriminar os campos?

gqferreira wrote:Obrigado Adelar, estou estudando Hibernate e estou conseguindo adaptar, mas e a questao do "SELECT * " ? Considerando que realmente precisarei de todos os campos, ainda sim é aconselhavel discriminar os campos?

Quando discrimina os campos a memória utilizadada é menor e a banda utilizada para a passagem dos dados do server para o cliente do banco é menor (este é o principal motivo para adotar esta prática).
Imagina que há uma tabela de 80 campos e preciso de 2 colunas, por exemplo.. todas as outras 78 ocuparão memória e banda de rede sem utilidade nenhuma..

Att.

Topico muito bom, a blog com o post lá realmente me ajudou muito, mesmo não estando trabalhando com isto agora, a questão do select vai fazer com que meus futuros programas sejam muito mais rapidos....

kkkkk

Notícias, artigos e o maior fórum brasileiro sobre Java