2011/6/28 Udlei Nattis <[email protected]> > Neste caso o que queremos é permitir que a ferramenta seja feita em > qualquer linguagem, não apenas a que vamos desenvolver inicialmente. >
Não seria uma otimização precoce? Como o Euler, eu também deixaria apenas as regras complexas para funções. O resto eu documentaria bem, de antemão, para criar uma API "modelo" que poderia ser mais facilmente portada para uma outra linguagem, e claro, com excelentes testes, tanto unitários como outros tipos. O mais difícil é conseguir iniciar com TDD (test-driver development). Depois o esforço extra se paga em pouco tempo. Também não estamos preocupados em esconder nada, inclusive é discutido na > empresa em montar o sistema em código aberto. Preferimos investir mais neste > hardware para garantir que transacoes, controle de estoque e geracao de > produtos sejam seguras do que deixar na mão dos programadores que geralmente > não entendem toda a complexidade do negócio. > Certo. Mas não esqueça que é mais difícil notar ineficiências/otimizar quando o SQL está enterrado dentro de funções. > Sabe me dizer onde encontro alguma documentação sobre? > Sobre o que? Roberto
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
