[SP-pm] DBIx::Class

[André Walker]

On Tue, Sep 17, 2013 at 07:38:16AM -0300, Alceu Rodrigues de Freitas Junior wrote:
> Em 16-09-2013 22:34, Eden Cardim escreveu:
>>http://mail.pm.org/pipermail/saopaulo-pm/2013/020344.html
>>Pra ser mais exato: "Se você quiser ser realmente eficiente com o banco,
>>acho que vai ter que abandonar o DBIx::Class"
>
> Para este caso de upsert Eden! Só para este caso!
> Use o contexto... não estou escrevendo uma especificação.

O contexto seria uma página de cadastro em que a pessoa tentaria inserir um
e-mail que já está no banco. Acho que não foi o Eden que saiu do contexto...

>> Geralmente "solução híbrida" é expressão sinônima de "super-engenharia".
>
> Na teoria parece bonito, mas vou te dar o lado prático da moeda.
>
> Em mainframe, os programas são em sua maioria em Cobol. Diferentemente de
> plataforma baixa, programas lentos custam mais dinheiro porque os
> fabricantes cobram, periodicamente, o valor de ciclos de processadores
> utilizados.
>
> Então se o programa em Cobol, depois de otimizado, ainda é considerando
> lento, os programadores descem para o C.
>
> Se com C a coisa ainda não ficou do jeito que queriam, vão mesmo para o
> Assembly.
>
> Você chamaria isso de super-engenharia?
>
> Para outro exemplo de "super-engenharia", vide Java Magazine 25, ano III,
> "Persistência Turbinada" que mostra que você pode abandonar o ORM de sua
> preferência e ir para o JDBC se o desempenho com o primeiro não estiver
> satisfatório.

Super-engenharia significaria inserir mais complexidade sem necessidade. O
Eden não estava dizendo que não há situações em que deve-se utilizar camadas
mais baixas! Tudo isso que você falou pode estar correto, mas não tem
absolutamente nada a ver com o tópico em discussão!

De certa forma, você está provando o ponto dele: você precisa construir uma
página de web com cadastro de e-mail, e começa a pensar em otimizações em C,
assembly, ciclos de processadores, etc. Não precisa de tanto :)

[]'s
André