Banco de dados enorme (mais de 50000 transaçoes diarias), hibernate VS jdbc

Bem cara, acho que o hibernate se aplicaria sim, sem problemas

tipo eu vejo as pessoas a reclamar do hibernate com poucos dados, dizem que consome muito, agora quanto mais muitos dados==???

Olá,

Fale um pouco mais das transações… isso pode nos ajudar a definir a melhor tecnologia para a camada de negócios.
Com relação a camada persistência, bom, se seu requisito não-funcional principal é performance, utilize DAO com JDBC
e queries otimizadas, dessa forma você não terá o overhead do framework e poderá ter total controle das queries.
Por outro lado, você terá um trabalho maior para implementação, já que não contará com as facilidades do mapeamento
objeto relacional do JPA. Lembre-se também que se utilizar queries com sintaxe “vendor-specific” irá comprometer a portabilidade
de sua aplicação com relação à base de dados… anyway, você pode adotar uma arquitetura híbrida com DAO utilizando SQLs otimizados
para as operações críticas e HIBERNATE para tratar de casos mais complexos (relacionamentos) mas não críticos com relação à performance.

[ ]'s

Porque ninguém nunca cita a possibilidade de se criar o próprio framework objeto-relacional ?

Olá!

Vamos imaginar uma história de ficção-científica … Num reino muito distante, sem prazos apertados e com uma receita infinita,
seu gerente de projetos decide que você deverá projetar e implementar um framework de persistência objeto-relacional que será
utilizado como padrão em todas as aplicações adiante. Sem saber da existência de outros frameworks com o mesmo propósito
você levanta os requisitos, features, etc… e define todo um esquema para o mapeamento objeto relacional, utilizando XML, annotations, etc.
Também define um gerenciador que desacopla as entidades e a tarefa de executar a persistência, e com isso também você consegue
um indepedência de fornecedor de banco… define também um mecanismo para integração com o container, para transações e utilização
de outros recursos do mesmo… OK …mas se você analisar os frameworks existentes você conclui que eles provavelmente contém todos
(e possivelmente muito mais) recursos que o seu próprio framework. Além disso, eles já passaram por revisões e testes, isto é, provavelmente
estão estáveis e são bem conhecidos, isto é, possivelmente existe uma quantidade significativa de profissionais que conhecem tais frameworks,
contudo, o seu framework proprietário não. Agora imagine o tempo de projeto, implementação e testes para implementar um framework completo
baseado em JPA? Seria realmente mesmo necessário fazer isso? Porque? A menos que o seu framework de persistência (e de forma geral, o seu
framework proprietário) possua um conjunto de features realmente distintas e superiores a de outros frameworks, não vejo um motivo forte o
suficiente para isso. Essa é a idéia geral de orientação a objetos, reutilização de código, de componentes e de frameworks… evitar de “reescrever
a roda” toda a vez… utilizar o genérico adicionando-se comportamento específico. Então creio que não construímos frameworks ao nosso “bel prazer”
devido a questões de orçamento, tempo, complexidade, padronização e qualidade.

[ ]'s

Bem, mas vamos imaginar uma história um pouco diferente, num reino não tão distante:

• as decisões técnicas são tomadas por líderes técnicos, ou seja, por gente que sabe o que está fazendo
• eu sei que a utilização de um framework existente vai encarroçar a minha aplicação, então decido utilizar JDBC puro na minha camada
  de persistência
• logo, a duplicação de código começa a aparecer, então é fica clara a necessidade de um framework para lidar com detalhes de persistência
• o projeto tem um tempo de vida longo (longo mesmo), então tão cedo não trabalharemos em outro projeto, ou ainda, projetos subsequente
  são sub-produtos do primeiro
• o projeto não precisa de 90% das features do super-framework, e eu preciso de uma única funcionalidade que o framework não cobre
• as features são implementadas conforme a necessidade

Sendo assim, não vejo nenhum absurdo em abrir mão de uma solução quando concluí-se que esta não atende às necessidades do projeto.

“As decisões técnicas são tomadas por líderes técnicos, ou seja, por gente que sabe o que está fazendo”

São?

[ ]'s

Porque ninguém nunca cita a possibilidade de se criar o próprio sistema operativo ?

schranko:

“As decisões técnicas são tomadas por líderes técnicos, ou seja, por gente que sabe o que está fazendo”

São?

[ ]'s

Sim, são. E diga-se de passagem, não sou um desses líderes, caso a intenção tenha sido ironizar a minha pessoa. E como o autor do tópico também resolveu ironizar, até +;

Genial… vamos criar nosso próprio SO??? Poderia se chamar Sulitonix e ter suporte nativo ao SCPS (Space Communications Protocol Specifications)!

[ ]'s

eu sou free lancer, os free lancer é que normalmente decidem que tecnologias usar,porque na maioria das vezes o usuario nem sabe o que é melhor para ele.
Mas é o seguinte, se tiverem que criar um sistema que tera os dados de algumas base de dados de por exemplo todas as faculdades e uma universidade que tem umas 20 faculdade espalhadas pelo pais, ou tipo se o sistema tera os dados de todas as escolas ou universidades do brasil,
é ai que eu pergunto novamente a opiniao de todos JDBC ou HIBERNATE»???
a vossa opiniao para mim é importante eu estou pensando em começar um projecto de desenvolvimento dum sistema grande, e vou desenvolver sozinho a principio,e ainda nao sei qual é a melhor forma de representar a minha persistencia

O hibernate desde que bem configurado (com cache de segundo nível e as consultas/joins bem desenhados) poderia resolver 100% dos seus problemas. mas se mesmo assim vc necessitar de algo muito específico, poderia utilizar o jdbc em conjunto com o hibernate, somente nestas partes onde ele não lhe atender.

Se vc estivesse utilizando Spring, e sua camada de persistencia estiver bem emcapsulada, poderia facilmente fazer isso, bastaria trocar entre o hibernatetemplate e o jdbctemplate conforme seus testes.

Minha opinião sobre frameworks própios é que geralmente trazem mais problemas que soluções. sofrem de defasagem tecnológica rapido ( aquela feature q vc implementou pq não tinha no hibernate aparece na próxima versão junto com outras 100, ai vc perdeu a razão de utilizar o seu framework) além de ter que perder tempo com treinamento do pessoal novo contratado. O correto IMHO seria vc extender o framework, criando a funcionalidade que vc precisa, e reutilizando todo o resto.

[]'s

Obviamente, utilizando o Hibernate vc terá o poder do ORM (mapeamento dos objetos para persistencia). Com cache de segundo nível utilizado corretamente e otimização de queries acredito que não terás grandes problemas. É bom tbm criar um próprio sistema de cache para as principais páginas, se possível.

Só uma coisa que não entendi: vc quer dizer com transações diárias o número de updates diários, sem contar as requisições?

:idea: :idea:Entao aqueles que eu vejo reclamando sobre o consumo excessivo de memoria do hibernate, se calhar é porque nao sao avançados no framework, e nao configuram e nao usam os recursos mais avançados do hibernate???
mas as vezes eu fico me perguntando, num select grande deixar uns 50000 objectos na memoria é doloroso para o pc, em jdbc eu achava que teria mais controlo do que fica ou nao na memoria, mas vendo bem mesmo no hibernate tambem poderei ter total controle :idea: :idea: :idea: :idea:

IMHO, acho que com a tecnologia avançada em memória que temos hoje, memória não seria um problema tão grande. Pode até ter problemas com o heap, mas nesse caso de ter 50k objetos na memória, pode usar a paginação. Em vez de trazer todos, faz uma estrutura que faz a paginação dos seus objetos, trazendo a página em memória qdo for necessário.