Bem como desenvolvedor Java, acho "javeiro" uma vulgarização, utilizador do Hibernate e apaixonado pelo Postgres, acho que devo me pronunciar. Apesar de muitos gostarem não há uma panaceia para todos os problemas em desenvolvimento. Ou melhor, não tenho conhecimento de ferramenta, linguagem ou framework que vá atender a todas as vontades e necessidades tantos do desenvolvedor como do dba e do cliente, infelizmente alguém sempre tem de sofrer. Mas, há saídas e formas interessantes de se fazer as coisas, que as deixam rápidas de desenvolver, seguras e com certa otimização. Infelizmente existe uma boa gama de programadores que acha que ou se usa tudo ou não se usa nada de uma ferramenta ORM. A meu ver e pela experiência que já tive fazendo alguns programas, há sempre a possibilidade de se mesclar os mundos. Muitas regras de negócios são e deveriam ser facilmente "embutíveis" no banco. O Hibernate, no caso, nos permite a maravilha de não ter que ficar fazendo o mapeamento objeto relacional, de modo manual, porém tem gente que acha que tudo tem de ser entregue ao mesmo. Há a possibilidade de se criar funções no Postgres e o fazer as chamadas pelo Hibernate, unindo assim as vantagens do Hibernate com a real função de um ótimo SGBD como Postgres. Evitando assim o uso, que ocorre atualmente, do banco como mero repositório de dados. Agilizando tanto o desenvolvimento quanto a manutenibilidade do mesmo, pois, estando as regras dentro do banco, a mudança ou correção de qualquer funcionalidade é mais rápida e limpa do que reescrever o código, seja em PHP, JAVA ou qualquer outra linguagem. Fora outras vantagens que vem a partir disso. Vejo que muitos programadores, atualmente, simplesmente jogam a responsabilidade de algo para cima de um ou outro framework e se der problema alega limitação do mesmo. O uso de chave compostas exige sim um pouco mais de trabalho no Hibernate mas, não é uma coisa impossível e muito menos inviável. Porém muitos programadores que já tive contato, pouco conhecem de banco, o que os impede - as vezes - de enxergar os problemas que estarão criando, pois acham muito mais prático usar chaves artificiais. O assunto de ORM sempre vai e volta aqui. Sinto se ofendi alguém mas esse é o meu relato com base na minha realidade e experiência.
Bruno E. A. Silva. Analista de Sistemas. 2012/9/11 Eduardo Alexandre <eduardog...@gmail.com>: > Em 11 de setembro de 2012 15:20, Flávio Alves Granato > <flavio.gran...@gmail.com> escreveu: >> >> Bem, vou pelo pensamento mais conservador. Se pode dar consequência então >> é de se pensar, pois pode dar consequência média e baixa pode dar problema a >> médio e longo prazo. > > > Dois pontos: > O desenvolvimento precisa atender a determinados níveis de qualidade e > velocidade de desenvolvimento. Se houver desenvolvedores na lista, sabem o > que é receber um pedido de um recurso mirabolante pra ontem e ser obrigado a > cumprir esse prazo. Geralmente esse fato se repete dia após dia, sendo tudo > urgente e pra ontem. > > Se eu for pensar no cenário ideal, diria que é melhor fazer o software "na > unha", otimizado para a melhor performance possível. Mas será que isso é > possível? :) > > Se não formos utilizar a tecnologia que pode ter consequência negativa, qual > usaremos? > > > Abraços, > ____________________ > Eduardo Alexandre > > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
