<p dir="ltr">Se colocar storage procedure no meio, tem que remover o argumento de que não se pode tratar usando o texto pois varia de acordo com os bancos. <br></p>
<p dir="ltr">No resumo, acho que, depois desse monte de respostas, *o melhor* caminho, é consultar se existe antes de inserir (apenas para ter certeza da mensagem de retorno e etc, isso não quer dizer que é para remover o unique da tabela) e só depois inserir. </p>
<p dir="ltr">Caso número de registros seja grande, ou o volume de acesso seja tão grande que esse count vai afundar todo o investimento, podemos pensar em mais soluções:</p>
<p dir="ltr">* criar um index com uma palavra fixa (md5, substr, soundex{?}) <br>
* cache ante brute force <br></p>
<p dir="ltr">Então, logo que recebido um email poderia se olhar no cache se esse mesmo já encontra em uso. <br>
Caso não encontre no cache, aí sim faria uma pesquisa no banco de dados, que, como existe o index, seria o custo quase mínimo que um request pode fazer e aí então gravar no cache (se existe grava, se não existe também grava) o retorno. </p>
<p dir="ltr">E aí na hora que criar e apagar os usuários têm que lembrar de atualizar o status do cache. </p>
<div class="gmail_quote">On Sep 15, 2013 10:49 PM, "Alceu R. de Freitas Jr." <<a href="mailto:glasswalk3r@yahoo.com.br">glasswalk3r@yahoo.com.br</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
----- Mensagem original -----<br>
> De: Eden Cardim <<a href="mailto:eden@insoli.de">eden@insoli.de</a>><br>
<br>
>>>>>> "Alceu" == Alceu R de Freitas<br>
> <<a href="mailto:glasswalk3r@yahoo.com.br">glasswalk3r@yahoo.com.br</a>> writes:<br>
><br>
> Alceu> Solli, Recentemente comecei a fazer alguns testes com<br>
> Alceu> TryCatch e até o momento me pareceu bastante satisfatório,<br>
> Alceu> mas você pode se pegar criando várias classes de exceção.<br>
><br>
> Um convite pro overengineering.<br>
<br>
Como por exemplo...?<br>
<br>
> Overengineering e otimização prematura ao mesmo tempo. E mesmo pra<br>
> otimizar, não precisa largar o DBIx::Class, se (e repito, *se*) você<br>
> cair num caso onde você precisar chegar nesse nível de otimização, é<br>
> só sobrecarregar as partes certas do código.<br>
<br>
Posto o que o Solli queria fazer, acho que posso deixar a questão de otimização prematura a critério dele.<br>
<br>
Eu DUVIDO que o DBIx::Class consiga ser mais rápido (executando um SELECT antes do INSERT) do que uma stored procedure que faça a mesma coisa ou use tratamento de exceções.<br>
<br>
> Alceu> Ou então fazer um esquema de cache experto (Memcached?)<br>
> Alceu> para os registros já inseridos no banco, isso tornaria a<br>
> Alceu> coisa toda mais eficiente.<br>
><br>
> Mais eficiente e mais errada, sujeito a race conditions insolúveis.<br>
<br>
Não se houver tratamento para exceções. Se estamos falando de cadastro/descadastramento de contas em um sistema, quantas vezes é provável isso ocorrer?<br>
<br>
> Alceu> De qualquer forma, o DBI tem o método err()<br>
> Alceu> (<a href="http://search.cpan.org/~timb/DBI-1.628/DBI.pm#err" target="_blank">http://search.cpan.org/~timb/DBI-1.628/DBI.pm#err</a>) para<br>
> Alceu> retornar um código numérico... claro que você teria que<br>
> Alceu> criar de antemão uma tabela com os códigos de cada banco de<br>
> Alceu> dados que você quer que sua aplicação suporte. Como<br>
> Alceu> DBIx::Class usa DBI, talvez você consiga ter esta mesma<br>
> Alceu> informação.<br>
><br>
> E porque isso é mais fácil ou rápido do que usar algo que é<br>
> naturalmente portável entre todos os backends que suportam SQL: uma<br>
> consulta antes do insert?<br>
<br>
Eu não lembro de ter escrito que isto seria mais rápido do que usar um SELECT antes do INSERT, apenas seria uma opção se ele quisesse trabalhar com tratamento de exceções.<br>
<br>
[]'s<br>
<br>
Alceu Rodrigues de Freitas Junior<br>
--------------------------------------<br>
<a href="mailto:glasswalk3r@yahoo.com.br">glasswalk3r@yahoo.com.br</a><br>
---<br>
A well-used door needs no oil on its hinges.<br>
A swift-flowing stream does not grow stagnant.<br>
Neither sound nor thoughts can travel through a vacuum.<br>
Software rots if not used.<br>
These are great mysteries -- The Tao Of Programming, 5.1<br>
<br>
=begin disclaimer<br>
Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
</blockquote></div>