André e demais colegas da lista:
Acho que o que todos nós queremos é uma ferramenta mais produtiva, correto?
Estou trabalhando como DBA em uma empresa que tem um sistema em Java com
cerca de 2200 tabelas, e umas 10.000 telas. Começaram este sistema há muito
tempo e, na época, inventaram um framework próprio. Claro, com os conhecimentos
que os mesmos tinham na época; portanto, o mesmo se encontra ultrapassado e de
difícil manutenção.
Aí os "gerentes" resolveram chamar uns supostos "consultores", que, entre
vários absurdos, indicaram o uso do banco de dados Caché, além de trocar o Java
pelo .NET - argumentando que a velocidade do Caché é superior ao PostgreSQL, e
a "produtividade" do .NET é "comprovadamente" superior ao Java. Também me
disseram que - pasmem - o código do .NET roda no Linux, argumentando que -
palavras deles - "a Microsoft não vive sem o Linux"...
Sim; creio que muitos da lista devem estar, neste momento, se contorcendo com
as gargalhadas...
Bom, agora estou tentando explicar aos "gerentes" que já temos uma equipe
qualificada em Java, que a linguagem e as ferramentas são gratuitas, que o
Linux é gratuito, que 90% dos clientes da empresa NÃO vão trocar o sistema
atual se o mesmo gerar mais custos (SO Windows Server + licenças do tal Caché);
que teremos que adquirir a licença do .NET (R$ 3.500,00, segundo os
"consultores"), etc e tal.
Aí então começamos à falar da persistência, e um dos "gerentes", que não sabe
o que é o Project e nunca escreveu um loop na vida, argumentou que "o Hybernate
não aceita chaves compostas"...
Ufa; estou resumindo uma discussão de algumas horas. No final, tive de abrír
o Google e pedí para ele me demonstrar qualquer documentação que favorecesse
seus argumentos.
Passada esta fase, tivemos uma outra reunião, onde os programadores mais
antigos da empresa estavam presentes e, junto com todos, optaram por continuar
com o Java, mas utilzando o JPA, mas só nas novas alterações. O código antigo
deve coexistir com o novo, sempre que possível. Se não, reescrever com uma
tecnologia mais produtiva.
E a pergunta que eu faço para os que já trabalham com o JPA é:
a - funciona realmente?
b - quais são as vantagens e desvantagens?
c - tem algum problema de performance?
d - utiliza chaves compostas sem problemas?
No aguardo,
Márcio de Figueiredo Moura e Castro
PS: não sei se deveria abrir um novo tópico, mas neste caso, me desculpem,
________________________________
De: Andre Fernandes <[email protected]>
Para: Comunidade PostgreSQL Brasileira <[email protected]>
Enviadas: Sábado, 2 de Janeiro de 2010 19:12:08
Assunto: Re: [pgbr-geral] Res: Uso de Campos Padrões
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
____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
