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

Pessoal se eu tiver um banco de dados que recebe diariamente muitas transaçoes (media mais de 50000 transacoes diarias) , para ter mais performance e tunning dos sql, é mais vantajoso usar o hibernate ou o jdbc.

1-sera que o hibernate se aplica em BD de grande porte?? ou apenas medio e pequeno??
2-sera que se eu usar o jdbc com os driver nativos da oracle e as classes nativas da oracle terei vantagem em relacao ao hibernate???

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? :slight_smile:

[ ]'s

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

[quote=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? :slight_smile:

[ ]'s[/quote]

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.