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
=begin disclaimer
Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
SaoPaulo-pm mailing list: [email protected]
L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
=end disclaimer
