2009/11/1 Leandro DUTRA <leandro.gfc.du...@gmail.com>: > Tenho testemunhado muitas dificuldades, não digo das linguagens em si > mas do ferramental associado, talvez até da cultura, em aproveitar as > características do ISO SQL presentes no PostgreSQL. Por exemplo, > javeiros bem razoáveis me dizem ser complicado trabalhar com domínios > ou com chaves compostas.
Não faço parte da categoria de "javeiros bem razoáveis" que vc se referiu, mas imagino que a complexidade está no mapeamento (javeiros videm anotação @IdClass) de chaves compostas da JPA. Da mesma forma, mapear tipos de dados definidos pelo usuário (aka UDT) e/ou domínios são tarefas não triviais para alguns framewirks e a complexidade dobra quando se utiliza JPQL, HQL, DQL ... O fato é que os frameworks para ORM da maioria das linguagens se preocupam muito mais com a interface e produtividade do desenvolviedor do que com robustez e consistência do modelo de dados. Os mesmos problemas descritos acima são encontrados no Doctrine (php), ActiveRecord (Rails) – Cpk contorna o problema –, SQLObject (python - SQLAlchemy é sua solução mais óbvia) e tantos outros. Voltando a discussão inicial, aconselho que independente da linguagem que vc escolher para escrever a sua aplicação, não utilize paradigmas de ORM/SQL Mappers/ para resolver *todos* os seus problemas porque voce possivelmente vai se complicar ainda mais. Também é aconselhável escolher linguagem que possue seus próprios conectores para a libpq [1] e que de preferência este conector tenha uma comunidade ativa de desenvolvimento, coisa que ODBC/ADO não tem. 1) http://www.postgresql.org/docs/8.4/interactive/libpq.html Abraço! -Leo -- Leonardo Cezar http://www.aslid.org.br http://postgreslogia.wordpress.com http://www.dextra.com.br/postgres _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
