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. > -- > Tarcisio F. Sassara > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- André de Camargo Fernandes
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
