[SP-pm] DBIx::Class

[Eden Cardim]

>>>>> "Alceu" == Alceu R de Freitas <glasswalk3r em yahoo.com.br> writes:

    Alceu> Quem precisa reler com mais atenção é você: se você critica
    Alceu> que usar stored procedures é uma otimização prematura e
    Alceu> depois muda de ideia... bem, decida-se.

Ok, vamos pro "be-a-bá", olha o aviãzinho! Seguinte:

1 - Usar SPs como implementação inicial de uma funcionalidade de
cadastro é uma otimização prematura. Os motivos são: 
1.1 - SPs raramente são portáveis entre implementações de backend.
1.2 - SPs aumentam a quantidade de trabalho envolvido no deploy
do banco de dados.
1.3 - SPs significam mais partes móveis, o que significa que mais
pontos de integração precisam ser testados.
1.4 - SPs podem sim ser mais lentas do que select+insert porque a
depender do caso, você precisa preservar locks durante a SP inteira e
o backend não tem como otimizar pra você, então é melhor que você seja
*muito bom* se for seguir esse caminho.

Bom, agora que revisamos o *básico*, vamos pra segunda parte:

2 - *se* (repito: *se*, condicional, ramificação) for constatado que
uma SP for de fato necessária como otimização (e repito, sãos raros os
casos) somente aí você sobrecarrega as partes relevantes das classes
envolvidas e chama a tua SP lindamente otimizada, mas só no ponto em
que estiver lento, não precisa arrancar o DBIx::Class inteiro.

    Alceu> Acho que você saberia como responder isto, mas não, não
    Alceu> resolve. Mas se a premissa de que o valor do cache está
    Alceu> correto falhar eu posso ter um exceção, capturá-la e
    Alceu> contornar a falha, repetindo o processo e descartando o
    Alceu> cache. É por isso que se chama excessão.

Bom, se não houvesse um motivo simples pra ignorar essa recomendação,
eu explicaria as outras desvantagens. O motivo simples é que um cache
como o memcached não é necessário pelo fato de que qualquer kernel
lançado a partir da década de 90 faz page caching pra você e faz de
uma forma muito mais eficiente que o memcached faria. O kernel pode
fazer isso porque ele tem acesso transacional a todos os pontos de
entrada e saída de dados do sistema. O memcached não tem.

    Alceu> Não sei de onde você tirou isto. Acho que os bancos de
    Alceu> dados que fazem cache em memória de índices também devem
    Alceu> estar todos incorretos (de acordo com seu raciocínio). Até
    Alceu> onde eu sei, quaisquer dados são elegíveis de serem
    Alceu> utilizados em um cache, principalmente os que não mudam com
    Alceu> frequência. Siglas de UF são dados transientes para você?

Novamente, um banco de dados pode fazer isso *internamente* porque ele
tem acesso transacional a todos os dados do banco, o memcached não
tem. E sim, os dados de um cache qualquer são *todos* transientes
porque a hierarquia de memória proíbe que *todos* os dados sejam
armazenados no cache: o custo é proibitivo. Logo, se a demanda
imediatata do sistema é por um volume de dados que ocupe todo o cache
disponível e que não sejam as siglas de UF, essas siglas vão
desaparecer do cache até que sejam requisitadas novamente.

    Alceu> Já nem tenho mais o e-mail original do Solli, mas se e-mail
    Alceu> é parte identificadora de uma conta (e com valores únicos
    Alceu> se configurado assim no BD), exatamente qual o problema de
    Alceu> eu fazer um cache fora do banco de dados para isto?

O problema é que se você tem um banco de dados que precisa ser
otimizado via cache externo, é bem provável que os registros de
cadastro não caibam todos na memória. O memcached não pode fazer isso
porque ele não tem acesso transacional (repetindo pra garantir que
leram dessa vez).

    Alceu> Aliás, eu não vejo porque me dar um trabalho de consultar
    Alceu> se um e-mail existe no BD antes de um INSERT se ele não é
    Alceu> chave primária ou faz parte de uma composta ou precisa pelo
    Alceu> menos ser único na base.

Falácia do espantalho? Isso é um cenário completamente diferente do
que está sendo discutido. A questão é que a *chave* ser única não te
salva de ter que fazer uma consulta antes de tentar inserir uma
duplicata. E nesse discussão específica, essa chave não é composta: é
o email.

    Alceu> Se um usuário tenta cadastrar-se mais de uma vez, com o
    Alceu> mesmo e-mail, repetidas vezes existe um problema maior do
    Alceu> que além da estratégia de usar cache.

A questão é bem mais provável que exista um erro de implementação na
tua estratégia de cache manual do que no caching do SO e pro BD. É um
ponto de falha adicional. E cadastro repetido é um cenário comum sim
em 2013, como por exemplo spam bots defeituosos.

    Alceu> Você diz que sim, mas se não aponta o motivo fica difícil
    Alceu> comprar a ideia. Fé é algo que não cabe aqui.

Você está ignorando os contra-pontos que já foram expostos na thread
antes, vou sintetizar aqui pra você (e pela última vez):

Consultar antes do insert:

1 - é trivial
2 - é rápido (tanto a implementação quanto a execução, assumindo o uso
de um banco de dados razoável)
3 - é portável
4 - é simples de ler (select email from tabela where email = 'foo em bar.com'
é a primeira coisa que se aprende em qualquer curso vagabundo de SQL)

Um mecanismo de excessões:

1 - Não é tão rápido assim (a resolução da pilha é particularmente
lenta, em qualquer linguagem)
2 - Não é portável (cada banco de dados tem seus próprios códigos de
erro)
3 - Não é trivial (requer conhecimento específico de todas as engines
de banco de dados envolvidos e requer um mecanismo de excessões
bem-planejado e funcional)

Não tem *nada* a favor das excessões nesse caso, exceto pra quem nunca
programou em nada além de java a vida inteira, aí *talvez* faça sentido.

-- 
Eden Cardim -- Insolide Soluções de TI Ltda.
+55 11 9644 8225
http://insoli.de