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. Yah! Muito! Existe situações que eles podem ser ignorados ou bem úteis.
> > 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. Concordo especialmente com a seguinte afirmação: "Não considero boa prática ter a estrutura do banco na aplicação". Existe um problema muito grande. Um pecado que os desenvolvedores estão cometendo: Estão tirando a regras do negócio do banco de dados e colocando-as na aplicação. > 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. Alguns problemas são pelo mal uso mesmo. Por exemplo: Deixar no modo debug onde é refeito toda hora o mapeamento. > 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. Depende muito, se você iniciar um projeto do zero e seguir as recomendações das bibliotecas você consegue um ótimo desempenho. O pior caso é quando você resolve adotar a ferramenta depois de o modelo estar pronto. Assim eu concordo. Fica uma droga. > 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. O problema é que em uma aplicação fazemos isto direto. Inserimos e pesquisamos registros em muitas sessões (telas). Se não abstrairmos, acabaremos repetindo muito código. Coisas como abrir e fechar conexão. E ainda existe o problema dos sistemas que devem ser portáveis. > > PS: o hibernate não é baseado no JPA, pelo que me recordo é o contrário. > Ah! Isso é um assunto interessante. Realmente, na prática, o JPA veio depois do Hibernate mas conceitualmente o Hibernate é baseado no JPA. JPA é uma especificação. A JPA foi uma tentativa de especificar uma camada de persistência. (Não sei dizer se foi uma tentativa bem sucedida) Hibernate é uma implementação. O hibernate é o cara realmente. Ele é baseado na especificação JPA. Quando os caras do Java começaram a criar a JPA usaram como base o Hibernate. Foi o caso clássico da implementação que veio primeiro da especificação. -- Tarcisio F. Sassara _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
