Hibernate: mais uma

Seu receio é quanto ao Oracle não aguentar o “tranco”?
Acho que quanto a isto vc não precisa ter medo!

Opinião minha, vamos ouvir as dos demais!

“lcmetzger”:

Seu receio é quanto ao Oracle não aguentar o “tranco”?
Acho que quanto a isto vc não precisa ter medo!

sei que o Oracle “aguenta o tranco”! o Oracle é um dos mais bancos de dados mais robustos que tem…

meu receio, talvez eu tenha sido um pouco exagerado, mas é com relação ao Hibernate. (eu tava olhando os SQL’s que ele faz por debaixo do pano, e achei meio exagerado, quanto mais relacionamentos tem, mais SQL’s)… esta base será meio grande, meu receio é com performance.

tem bastante gente usando Hibernate aqui, eu gostaria que deixassem sua opinião

Humm…

Existe uma propriedade de mapeamento chamada “LAZY”, e se não me engano ela serve justamente para evitar que o hibernate carregue as classes filhas de uma dada classe.
por exemplo: 1 Cliente possue 100.000 títulos, se carregar cliente, não serão carregados os títulos, a não ser que se chame o método getTitulos da classe cliente.

Corrijam se eu estiver enganado.

Outra solução seria criar um DAO específico para cada situação, onde você pode manipular seu próprio SQL.

Eu to trabalhando com um sistema de megalojas, catálogos, produtos, essas coisas.

Um case que a gente quer fazer é de uma loja que tem uns 10 mil catálogos, e uns 200 mil produtos, sendo que um produto aparece em mais de um catálogo e obviamente os catálogos têm vários produtos…

Além disso, cada produto tem atributos, que podem ser String, Integer, Float, Date, etc… já deu pra ver como é grande, neh??

Com lazy evaluation eu consigo usar um objeto persistente Catalog. E tudo funciona uma beleza. Recomendo altamente trabalhar com lazy inverse collections, sempre usar inverse List quando vc tem ordenação artificial, e evitar ao máximo usar composite keys.

Assim, dá pra fazer coisas muito grandes do mesmo jeito fácil que a gente faz coisas pequenas…

[]s!!

obrigado pela resposta!

o “lazy=true” é altamento recomendado sim…

mas este “inverse” eu não estou muito ligado como funciona, poderia me explicar melhor?

grato pela ajuda

o inverse é o seguinte,
em vez de ter uma tabela para os mapeamentos, na tabela “filha” tem um campo apontando para a tabela “pai”

e o hibernate busca os relacionamentos ali

sobre o inverse=true, o que ele faz neste exemplo?

Player:

<set name="players" cascade=”all” inverse=”true” lazy=”true”>
<key column="team_id"/>
<one-to-many class="example.Player"/>
</set>

Team:

<many-to-one name="team" class="example.Team" column="team_id"/>

determinar um Team que um Player pertence? isto eu consigo fazer ser precisar deste “inverse=true”, não estou entendendo…

obrigado

mas sem o inverse=true, tu precisa de mais uma tabela para fazer o mapeamento (no set) com o inverse=true não precisa

eu estava estudando o Hibernate, e descobri mais uma dica legal para otimizar a performance, é definir algumas classes como “proxy”

em um one-to-many existe a opção lazy=true para não carregar o relacionamento automaticamente… já em um many-to-one o relacionamento é carregado automaticamente também…

session.load(Player.class, pk)// carrega o Team tb, a não ser que o Team esteja definido como um proxy! aí vc consegue fazer uma lazy inicialization neste caso tb!

“dukejeffrie”:

Recomendo altamente trabalhar com lazy inverse collections

certo, mas no que o inverse=true pode alterar na performance ?