[SP-pm] DBIx::Class
Alceu Rodrigues de Freitas Junior
glasswalk3r at yahoo.com.br
Tue Sep 17 03:38:16 PDT 2013
Em 16-09-2013 22:34, Eden Cardim escreveu:
>
> Concordo com todos os pontos, exceto o 1.4: DBI e DBIx::Class vão
> estar sujeitos ao mesmo problema. Eu não manjo muito de stored
> procedures em outros bancos, mas no Oracle consigo ter controle
> granular de transação, então não vejo este problema que você levanta.
>
>
> Qual parte de *a depender do caso* não ficou clara? E não, tanto o DBI
> quanto o DBIx::Class não excluem a possibilidade de se usar SPs, estou
> repetindo isso durante a thread inteira e você insiste em trazer isso de
> volta. Não é uma briga DBI vs SPs, a questão é que discutir sobre SPs
> com quem ainda está cadastrando usuários é um exercício em futilidade.
Não é Eden. Se eu quiser fazer upsert e que tenha um desempenho maior
vou ter que descer até o banco de dados. Dá para fazer conforme você
demonstrou, talvez a diferença de velocidade seja desprezível, mas
enfim... não é fútil a discussão.
> Que bom que você se deu ao trabalho de ajudar os monges mais novos!
> É muito chato quando você escreve respostas achando que todos devem
> concordar com você sem um racional!
>
>
> Não compreendo a tua retórica... 2 parágrafos atrás a reclamação era de
> pedanteria, agora é transferência de ônus da prova? Quando as pessoas
> apelam pra esse tipo de retórica inconsistente, geralmente é uma
> tentativa de *vencer* a discussão e não de enriquecê-la.
Eu não preciso vencer a discussão: vou ganhar o que com isso?
>
> "In God we thrust: all others must bring data".
>
>
> Pornografia já? Tem menores de idade, e o próprio deus, lendo ;)
Deus não lê e-mails: ele tem um programa do Yahoo! para fazer isto para
ele (vide Todo Poderoso). :-)
>
> Eu não me lembro de ter dito para arrancar o DBIx::Class inteiro...
> onde foi que eu escrevi isto mesmo?
>
>
> 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.
> Mas memcached foi espeficamente a solução que você recomendou... Agora
> que você mudou o discurso pra cache genérico, eu concordo contigo,
> genericamente.
Fato. Mas como você apontou, não precisa ser o Memcached. Pode ser
qualquer coisa, de IPC a modperl para criar cache.
> O verbete sobre Exception Handling no wikipedia é uma boa introdução,
> mas existem pré-requisitos de conhecimento que não cabem nessa thread,
> por isso vai ficar como exercício ao leitor.
Você já fez o suficiente dando uma referência.
Lembre-se, tem crianças lendo, então não parta da premissa de
pré-requisitos. ;-)
> Mas é verdade que é uma
> questão particular minha não gostar de excessões, não por "ranço" (seja
> lá o que isso signifique nesse contexto)
"Nojinho" do Java e similares... aquelas linguagens de programação
corporativas, morte ao Bill Gates e todo aquele blablabla...
> mas porque na minha visão elas
> são um convite pra violação do princípio de menor conhecimento (também
> conhecido como Law of demeter) e toda a super-engenharia que acompanha e
> foi demonstrada nessa thread.
Isso é assunto para outra thread. Mas até tomar água em excesso faz mal.
> 1 - É difícil ter desempenho superior sem sacrificar alguma coisa,
> como abstração ao banco de dados. Geralmente uma solução híbrida
> funciona melhor do que tentar procurar pela bala da prata.
>
> 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.
>
> Ah, mas que mal humor... Se você aparecer no próximo ES te pago uma
> cerveja de qualidade pra ver se melhora. ;)
>
Vê como eu não preciso "vencer" a discussão para ganhar alguma coisa? ;-)
[]'s
Alceu
More information about the SaoPaulo-pm
mailing list