[SP-pm] DBIx::Class

Renato Santos renato.cron at gmail.com
Sun Sep 15 19:01:59 PDT 2013


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.

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.

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:

* criar um index com uma palavra fixa (md5, substr, soundex{?})
* cache ante brute force

Então, logo que recebido um email poderia se olhar no cache se esse mesmo
já encontra em uso.
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.

E aí na hora que criar e apagar os usuários têm que lembrar de atualizar o
status do cache.
On Sep 15, 2013 10:49 PM, "Alceu R. de Freitas Jr." <
glasswalk3r at yahoo.com.br> wrote:

>
>
> ----- Mensagem original -----
> > De: Eden Cardim <eden at insoli.de>
>
> >>>>>>  "Alceu" == Alceu R de Freitas
> > <glasswalk3r at yahoo.com.br> writes:
> >
> >     Alceu> Solli, Recentemente comecei a fazer alguns testes com
> >     Alceu> TryCatch e até o momento me pareceu bastante satisfatório,
> >     Alceu> mas você pode se pegar criando várias classes de exceção.
> >
> > Um convite pro overengineering.
>
> Como por exemplo...?
>
> > Overengineering e otimização prematura ao mesmo tempo. E mesmo pra
> > otimizar, não precisa largar o DBIx::Class, se (e repito, *se*) você
> > cair num caso onde você precisar chegar nesse nível de otimização, é
> > só sobrecarregar as partes certas do código.
>
> Posto o que o Solli queria fazer, acho que posso deixar a questão de
> otimização prematura a critério dele.
>
> 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.
>
> >     Alceu> Ou então fazer um esquema de cache experto (Memcached?)
> >     Alceu> para os registros já inseridos no banco, isso tornaria a
> >     Alceu> coisa toda mais eficiente.
> >
> > Mais eficiente e mais errada, sujeito a race conditions insolúveis.
>
> 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?
>
> >     Alceu> De qualquer forma, o DBI tem o método err()
> >     Alceu> (http://search.cpan.org/~timb/DBI-1.628/DBI.pm#err) para
> >     Alceu> retornar um código numérico... claro que você teria que
> >     Alceu> criar de antemão uma tabela com os códigos de cada banco de
> >     Alceu> dados que você quer que sua aplicação suporte. Como
> >     Alceu> DBIx::Class usa DBI, talvez você consiga ter esta mesma
> >     Alceu> informação.
> >
> > E porque isso é mais fácil ou rápido do que usar algo que é
> > naturalmente portável entre todos os backends que suportam SQL: uma
> > consulta antes do insert?
>
> 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.
>
> []'s
>
> Alceu Rodrigues de Freitas Junior
> --------------------------------------
> glasswalk3r at yahoo.com.br
> ---
> A well-used door needs no oil on its hinges.
> A swift-flowing stream does not grow stagnant.
> Neither sound nor thoughts can travel through a vacuum.
> Software rots if not used.
> These are great mysteries -- The Tao Of Programming, 5.1
>
> =begin disclaimer
>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20130915/39a5dcca/attachment.html>


More information about the SaoPaulo-pm mailing list