>>>>> "GF" == Guimarães Faria Corcete DUTRA, Leandro <l...@dutras.org> writes:
GF> Há pouquíssimos ORM que tenham um mínimo de qualidade. GF> Lembro do SQL Alchemy, do Python, e acho que o Diogo havia me dito que GF> o Rails estava com um decente opcional na versão três.O DBIx::Class também é
bastante razoável.
GF> Mas os ORMs geralmente atrasam o resultado, introduzindo problemas.Nem sempre, a armadilha é que eles aceleram um milestone, e depois
atrasam outras, por isso a dificuldade de justificar o não-uso de um ORM
prum gerente de projeto, ainda mais esses "gerentes" que trabalham ad hoc e chamam de "ágil".
GF> A questão não é desempenho… e programar sem ORM não é mais difícil que GF> usar os ORMs mais populares. Só exige um mínimo de conhecimento de GF> dados.Não é mais difícil, mas pode ser trabalhoso, e reconheço que em boa
parte dos casos, não existe saída fácil. Mas existe um problema
recorrente em desenvolvimento que é inflar os dados normalizados do
banco pruma estrutura de dados sã que o teu software pode consumir, e
vice-versa, uma abstração boa pra esse problema pode acelerar sim o
desenvolvimento sem comprometer a qualidade do banco e das rotinas de
acesso.
–
Eden Cardim
+55 11 9644 8225
e...@insoli.de
Insolide Soluções de TI Ltda.
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
