2008/4/15, Nâmio Evangelista <[EMAIL PROTECTED]>: > > Normalmente, problemas como esse acontece quando se tem um programador ou > analista desavidado, que acha que o Hibernate é o "rei da cocada preta"; que > só basta criar as classes e os seus respectivos arquivos de mapeamente que > está tudo tranqüilo.
De fato. > Existe muitas maneiras de otimizar o mapeamento das classes. Um estudo > detalhado desta modelagem se faz necessário para obter um ganho de > performance significativo. Tomar os devidos cuidados com relação à > identidade de objetos é de suma importância para não vir a ter decepções no > futuro; saber modelar a cardinalidade e a navegabilidade entre as > associações de classes também é primordial. Existe uma maneira muito mais simples: faça-se a modelagem dos dados, e o Hibernate (ou o que mais se for usar) que se adapte a isso. Na minha experiência, 'profissionais Hibernate' dificilmente querem se moldar a um modelo de dados são. > O problema que o autor deste artigo está enfrentando, eu também passei, > usando Oracle, quando estava iniciando os trabalhos com Hibernate. A > diferença é que pesquisei bastante antes de sair falando besteiras a > respeito da framework. Que autor, que artigo? Que besteiras? Você está respondendo a uma dúvida de um colega, que não merece ser tratado desse jeito. > Parto do princípio de que se dentre milhares de pessoas que utilizam > Hibernate (ou NHibernate), apenas uma, duas ou até dez pessoas falam > asneiras desta framework, o problema está no profissional e não na > framework. Primeiro, o que é NHibernate? Segundo, leve em consideração que ferramentas não existem no vácuo, mas têm um caldo de cultura que as acompanham. A cultura Hibernate é francamente hostil à modelagem de dados. > Fico a imaginar como este autor se sairia tendo de usar um banco-de-dados > como o Caché, DB4O, ou qualquer outro banco-de-dados orientado a objetos. Justiça seja feita, esses SGBDOOs saem-se relativamente bem com a estupidez normalmente gerada pelo Hibernate. Com o contraponto de que são praticamente inúteis para tudo o mais em comparação com um SGBD SQL, e que é quase impossível criar outros programas para usar a mesma base de dados. Relatórios, então… -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED] _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
