Oi, bom dia.
Qual é a melhor tecnologia para trabalhar com bancos de dados relacionais?
Hibernate 
Mas, entre JDO e JDBC, fico com JDO. No entanto, quais são suas pretensões? Aprender o funcionamento de persistência sobre RDBMS em Java ou ter produtividade?
Aprender hehe
Então opte por JDBC. Depois que você tiver certeza de que já possui todos os conceitos de JDBC bem acomodados, tente Hibernate ou JDO (ambos estão na MundoJava deste mês, em artigos meu e do Rodrigo Urubatan, respectivamente).
Valeu cara!
O JDBC eu já estou legal … fiquei estudando um tempinho, agora precisava de algo melhor 
Hibernate vs JDO:
- Qual as maiores diferenças?
- Um é “melhor do que o outro”?
- Qual tem mais suporte para trabalhar com SQL?
depende do que tu precisa, mas na maioria das aplicações que são construidas do zero, eu escolho o JDO 
se tu precisar integrar com algum banco de dados ja existente, pode usar JDO ou hibernate, mas isto é mais natural para o hibernate, no JDO depende de extensões de cada fabricando pois isto não faz parte da especificação
o JDO não tem suporte para ti escrever SQL direto, só JDOQL
o hibernate utiliza a HQL (Hibernate QUery Language) mas tudo o que ele não entender, ele passa para o servidor SQL, pelo menos na versão 2 que utilizo
o JDO é um padrão especificado pelo JCP, o Hibernate não
existem diversos fornecedores de implementações de JDO, o que utilizo no momento é o jcredo, tem uma versão free muito boa
o Hibernate só tem um fornecedor
a JDOQL é basicamente java (sim, utiliza um subset do java como linguagem de pesquisa, uma linguagem a menos para aprender )
a HQL é uma mistura de SQL com linguagem de consulta orientada a objetos, se não me engano baseada na definida pela ODMG
bom, é mais ou menos isto
Valeu cara, mesmo! … se bem que o que você falou so dificultou mais a decisão :mrgreen:
Última dúvida: não tem um pacotão simples pra brincar com ADO da Micro$soft?
Para quê você vai querer mexer com ADO?!?!?!!? :shock:
É tão ruim assim? Não compensa de maneira nenhuma? Zero vantagens emcimad o JDO e Hibernate?
Meu mundo caiu 
Zero vantagens? Eu diria que você tem (-1*(Integer.MAX_INT)) vantagens. ADO é coisa apenas da Microsoft, não é padrão Java. Logo, para que usá-lo? Se quiser algo na linha do ADO, use JDO/Hibernate mesmo.
Eu adoro esse fórum.
Cara muitíssimo obrigado
Eu prefiro JDBC…
Mais performático, padronizado e limpo.
O JDO pode tornar um sistema simples de O-R, em um enorme problema.
[]'s
Oziel,
por exemplo,
que tipo de problema??
Pequena lista de problemas:
1 - Especificação instável (existem diferenças de uma spec para a outra)
2 - Problemas de DEBUG e LOGGING (tudo fica escondido)
3 - Excesso de abstração na modelagem da persistência (nada fica claro em termos de responsabilidade)
4 - Problemas com Fail-Over e HA (fica na dependência do fornecedor)
5 - Um Arquiteto ou Projetista Mal-Educado pode achar o JDO a solução de todos os problemas, o que não é verdade.
6 - Incompatilibilidades de Deploy em ApplicationServers diferentes ( no JBoss é diferente do Sun One, que é diferente do WebSphere)
Ou seja, na minha opnião, o JDO ainda é muito imaturo como framework de persistência, alem de ser uma carroça pelo excesso de abstração fornecido pelo framework.
Em qualquer aplicação J2EE eu não o indicaria. É melhor e menos problemático fazer com EntityBeans…
Para J2SE pode ser legal.
[]'s
[quote=“ozielneto”]Pequena lista de problemas:
1 - Especificação instável (existem diferenças de uma spec para a outra)
[/quote]
melhorou bastante da 1.01 para 2.0 que esta sendo projetada agora, mas só existe uma especificação até hoje (tudo bem, duas versões, a 1.0 e a 1.01) e não tem conflito nenhum entre elas, 100% de compatibilidade
na 2.0 ainda não se sabe direito pois fizeram apenas a 1a reunião para conversar sobre o que poderia ser incluido nela
então este argumento não tem pé nem cabeça
exatamente igual a um CMP, tu não vai conseguir debugar o codigo utilizado pelo container para salvar teu objeto no banco, e não vi nenhuma implementação de JDO até hoje, que não tivesse seu logging feito por log4j onde tu pode configurar todo o log que tu quiser
ahh, e se não me engano, a ideia de uma engine de persistencia, seja JDO, Hibernate, CMP, OJB, … é exatamente você não ter de debugar a persistencia, isto tem que estar fucnionando, caso contrario, mude de fornecedor (este é o unico problema que vejo no hibernate, não posso mudar de fornecedor )
fica claro sim, é responsabilidade do programador implementar a logica de negocio, e responsabilidade do fornecedor da engine JDO de implementar a persistencia
coloque seus objetos persistentes atraz de um DAO que o resto da aplicação não precisa e nem deve ficar sabendo que esta sendo utilizado JDO para persistencia
bom, como todos os dados ficam salvos no banco de dados, não vejo problema nenhum com Fail-Over, e HA não é um problema que a camada de persistencia deve cuidar,
JDO não é um container de nada, é apenas uma especificação para uma biblioteca/layer de persistencia
mas mesmo assim, a maioria dos fornecedores se integra dom um application server e utiliza estas caracteristicas do mesmo
se tu quiser HA, coloca um Session Facade na frente da tua camada de persistencia e pronto
não existe um Golden Hammer (é assim que se escreve?? acho que escrevi Hammer errado), isto é, não existe solução para todos os problemas, mas quando se fala de persistencia, acho que JDO ou Hibernate são sempre melhores de se utilizar do que um Entity Bean
ja que implementam o mapeamento O/R muito bem, e não tem todo o overhead de processamento remoto em uma camada da aplicação que deveria se preocupar apenas com persistencia
ahh, mas e os CMP?? é, ai tu tem que ficar mapeando um EJB para um DTO para poder passar aquele valor para outra camada da aplicação, pois não é possivel, e concordo, nem deveria ser, passar uma referencia para um EJB local para outra camada
ai em vez de mapear de ER para OO tem que mapear de OO para OO, isto sim que chamo de trabalho inutil
o que o JDO tem a ver com deploy em um application server?? é apenas um biblioteca que tem que estar disponivel para a tua aplicação, a qual tem que ter acesso aos arquivos de configuração desta, se colocar tudo dentro do mesmo era ja ta resolvido, não tem diferença nenhuma de deploy de uma aplicação utilizando JDO, mesmo pro que o deploy é apenas de um jar e arquivos de configuração que serão acessados pela tua aplicação
a não ser que tu queira dizer da integração entre a engine de JDO e do application server, mas isto, eu acho que nem deve ser feito mesmo, não esta na especificação, e basta colocar alguns session bean para prover o serviço de persistencia e pronto, o resto da tu aplicação não vai nem deve ter acesso ao PersistenceManagerFactory
bom, opinião não se discute, mas acho que você deveria rever os motivos, por que os apresentados aqui estavam praticamente todos furados,
quanto a fail over e HA, depende de como você vai implementar o sistema e de opinião pessoal (de quem deve prover estes serviços)
agora, de resto …
PS.: acho que escrevi demais, sorry.