2010/1/2 Andre Fernandes <[email protected]>: > 2010/1/2 Tarcísio Sassara <[email protected]> >> >> 2010/1/2 Leonardo Cezar <[email protected]>: >> > 2010/1/1 Tarcísio Sassara <[email protected]>: >> >> Ainda não conheço uma biblioteca/framework ORM que faz uso adequado de >> >> chaves naturais compostas. >> > >> > php: doctrine, propel; >> > python: SQLAlchemy; >> > ruby: DataMapper; >> > java: qualquer framework baseado na porcaria do JPA, por exemplo >> > hibernate; >> > >> > Abraço! >> > >> >> Opá, >> Da lista conheço o SQLAlchemy, o Propel e o Doctrine. >> >> Acho que o Doctrine superou o Propel. >> E no site do Doctrine diz: "Avoid composite keys" >> >> >> http://www.doctrine-project.org/documentation/manual/2_0/en/best-practices#avoid-composite-keys >> >> Se da o suporte mas não recomenda o uso, não é legal. >> >> O ORM provido pelo Django também não faz direito (faz tempo que não >> dou uma olhada). >> >> >> Para novas aplicações criadas isso não é muito problemático. É só >> seguir as convenções, mas quando é preciso migrar deve dar uma dor de >> cabeça. >> >> > > Boa tarde, > > Honestamente, o uso de ORMs é um assunto deveras polêmico. > > Eu, pessoalmente, sou contra. Não considero boa prática ter a estrutura do > banco na aplicação, não vejo razão de transportar a mesma para a aplicação, > ela não precisa saber quais são as tabelas que se usa no banco. A modelagem > do banco de dados pertence ao banco de dados. > E também já vi muitos problemas de desempenho e más implementações quanto a > muitos aspectos referentes ao banco em diversos ORMs de mercado. Incluindo > Doctrine, Propel, Hibernate, entre outros. Mas isso é minha visão pessoal. > > Por outro lado, tenho amigos que são excelentes desenvolvedores (eu sou > analista de dados, mesmo sabendo programar não tenho visão de programador) > que adoram o uso de ORMs. Muitos deles gostam de doctrine para PHP e > Hibernate para Java. Mesmo ao apontar os problemas que encontrei nessas > ferramentas, eles consideram que esses ORMs são ótimas alternativas e ajudam > muito. Mesmo discordando tenho de aceitar a opnião deles pois assim é o > mundo do desenvolvimento de software: há diversas frentes, e quase nunca > apenas uma está correta. > > Eu, pessoalmente, considero melhor prática usar visões e procedures para > acessar dados do banco ou mesmo alterá-los, com poucas excessões. O programa > não precisa saber o que está em cada tabela, precisa apenas solicitar que, > por exemplo, insira um novo cliente e mandar os dados dele. E depois precisa > ler os dados do mesmo, não se preocupando se tem 1, 2, 3, ou mais tabelas > que compooem essa informação. > Essa é a minha visão, é como faria. Mas se entrarmos em discussão quanto a > isso a coisa vai longe, é um assunto muito polêmico. > > Abraços, > André. > > PS: o hibernate não é baseado no JPA, pelo que me recordo é o contrário.
Considerando que JPA eh apenas a especificacao, como seria possivel JPA *implementar* alguma coisa??? Realmente estou curioso para entender onde estou equivocado ... -Leo -- Leonardo Cezar http://www.aslid.org.br http://postgreslogia.wordpress.com _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
