----- Mensagem original ----- > De: Eden Cardim <[email protected]> >>>>>> "Alceu" == Alceu R de Freitas > <[email protected]> writes: > > Alceu> Eu DUVIDO que o DBIx::Class consiga ser mais rápido > Alceu> (executando um SELECT antes do INSERT) do que uma stored > Alceu> procedure que faça a mesma coisa ou use tratamento de > Alceu> exceções. > > Relê isso (grifado com asteriscos pra não passar dessa vez): > > **************************************************************** > >> *se* você cair num caso onde você precisar chegar nesse nível > >> de otimização, é só sobrecarregar as partes certas do código. > ****************************************************************
Quem precisa reler com mais atenção é você: se você critica que usar stored procedures é uma otimização prematura e depois muda de ideia... bem, decida-se. > Alceu> Não se houver tratamento para exceções. > > Como o tratamento de excessões resolve a race condition? Acho que você saberia como responder isto, mas não, não resolve. Mas se a premissa de que o valor do cache está correto falhar eu posso ter um exceção, capturá-la e contornar a falha, repetindo o processo e descartando o cache. É por isso que se chama excessão. > Alceu> Se estamos falando de cadastro/descadastramento de contas > Alceu> em um sistema, quantas vezes é provável isso ocorrer? > > Toda vez que for feito um cadastro, toda santa vez. O debug disso vai > ocupar um estagiário por 2 meses. A solução que vão encontrar: remover > o caching. É melhor não fazer, nem recomendar, de primeira. Caching é > para dados *transientes*, contas de usuário não são transientes. Não sei de onde você tirou isto. Acho que os bancos de dados que fazem cache em memória de índices também devem estar todos incorretos (de acordo com seu raciocínio). Até onde eu sei, quaisquer dados são elegíveis de serem utilizados em um cache, principalmente os que não mudam com frequência. Siglas de UF são dados transientes para você? Já nem tenho mais o e-mail original do Solli, mas se e-mail é parte identificadora de uma conta (e com valores únicos se configurado assim no BD), exatamente qual o problema de eu fazer um cache fora do banco de dados para isto? Aliás, eu não vejo porque me dar um trabalho de consultar se um e-mail existe no BD antes de um INSERT se ele não é chave primária ou faz parte de uma composta ou precisa pelo menos ser único na base. Se um usuário tenta cadastrar-se mais de uma vez, com o mesmo e-mail, repetidas vezes existe um problema maior do que além da estratégia de usar cache. > Alceu> Eu não lembro de ter escrito que isto seria mais rápido do > Alceu> que usar um SELECT antes do INSERT, apenas seria uma opção > Alceu> se ele quisesse trabalhar com tratamento de exceções. > > OK, uma opção com *fortes* contra-indicações. > Você diz que sim, mas se não aponta o motivo fica difícil comprar a ideia. Fé é algo que não cabe aqui. []'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
