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.
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.
A
Adelar
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.
T
tinorberto
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/
A
AbelBueno
Adelar:
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…
veja bem essas duas queries:
select id, nome, descricao from tabela where id = 2
select id, nome, descricao from tabela where id = 5
para o banco de dados, são duas queries diferentes, portanto no cache vai ter uma versão de cada… com prepared ficaria:
select id, nome, descricao from tabela where id = ?
daí o banco faria cache, independente do valor…
R
Romildo_Paiter
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.
A
Adelar
Pois é, o hibernate tem muitas otimizações prontas, o que facilita muito na hora de desenvolver e manter depois os bancos.
Att.
G
gqferreira
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. :oops:
Mas se nao usar o hibernate, vou ver se troco o createstatment pelo prepared…
:thumbup:
A
Adelar
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.
G
gqferreira
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 :lol: ) nao tem conhecimento de hibernate.
A
Adelar
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.
G
gqferreira
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?
A
Adelar
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.
E
EngTI
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
G
gqferreira
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.
Sim mas, considerando que eu precisasse pegar os 80 campos mesmo?
