2011/10/13 Shander Lyrio <[email protected]>: > Em 13-10-2011 11:49, Guimarães Faria Corcete DUTRA, Leandro escreveu: >> Pois é, e o código tem de capturar o NOT FOUND como qualquer outro >> erro, e tratá-lo, seja abortando, convertendo num INSERT ou seja lá o >> que fôr correto no caso. > > Mas aí você não se contraria quando disse que era melhor fazer tudo em > uma única consulta?
Eu? Eu falei que não era para fazer consulta nenhuma, só executar a operação que se espera a mais comum primeiro, capturar eventuais erros (inclusive tupla não encontrada num caso, preexistente noutro) e então decidir se executa a outra. > Desta forma ele faria sempre em duas Pelo contrário. Geralmente faz‐se apenas uma operação, em vez de obrigatoriamente uma consulta e mais uma operação. > quer dizer que com o ORM tudo seria mais eficiente, no mínimo igual. Não. Porque ele afasta o desenvolvedor do SQL, impondo uma mentalidade imperativa em vez da declarativa nativa; e porque ele tem o estado da base replicado na aplicação, impondo custos adicionais. > Eu já havia feito estas contas, mas não havia pensando na possibilidade > de tratamento do notfound, mesmo assim o ORM é ainda é mais econômico. Isso seria absolutamente impossível. _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
