[SP-pm] DBIx::Class

[Leonardo Ruoso]

Deve haver alguma aplicação onde o benefício de guardar o valor do md5 de
uma string como BINARY/BYTEA em oposição ao próprio valor da string e
deixar o índice BTREE fazer seu trabalho compensará → provavelmente é a
mesma aplicação que vai notar benefício real em adotar largura fixa em
detrimento de XML para intercâmbio de dados. Felizmente eu ainda não tive
de colocar minhas mãos em nenhuma delas. Infelizmente eu já tive de lidar
com CNAB e com chaves artificiais onde cabiam chaves naturais suficientes
na minha vida…

Acabamos de modelar aqui um sistema, em que algumas tabelas contém milhões
de registros…

Adivinha qual vai ser a chave das regiões brasileiras (hierarquia desde
país até setor censitário passando por região, uf, meso, micro, municipio,
distrito e subdistrito)?

br.se.sp.regiao-metropolitana-de-sao-paulo.sao-paulo.sao-paulo.moema-indianapolis.moema.av-indianapolis-2000-2200

Servidor com 32 cores e 64GB de RAM?

R$ 10 mil reais por ano

Custo de manutenção de sistemas?

Incalculável!

Galera:

Chave natural é tudo de bom!
Chave composto é lindo e funciona!

Não se esqueça que dizer para os usuários que um email já está cadastrado
permite atacar sua base de usuários :)



Em 15 de setembro de 2013 17:17, Lucas Mateus <
lucasmateus.oliveira em gmail.com> escreveu:

>
>         É disso que to falando, usar o MD5 mesmo (binário) e não md5 em
> hexadecimal, e acho sim muito comum emails com mais de 16 bytes.
>
>         E se executar a query já passado o email com o md5, sem precisar
> usar a função do BD é ainda melhor, ja que o BD faz o hex por conta própria.
>
>
> mysql> show create table users_2;
>
> +---------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
> | Table   | Create Table
>
>                                                                |
>
> +---------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
> | users_2 | CREATE TABLE `users_2` (
>   `email` varchar(60) default NULL,
>   `email_md5` binary(16) default NULL,
>   KEY `idx_email` (`email`),
>   KEY `idx_email_md5` (`email_md5`)
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
>
> +---------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
> 1 row in set (0.00 sec)
>
>
> mysql> select email from users_2 where email = 'teste967847 em domain.com';
> +------------------------+
> | email                  |
> +------------------------+
> | teste967847 em domain.com |
> +------------------------+
> 1 row in set (0.21 sec)
>
> mysql> select email from users_2 where email_md5 = unhex(md5('
> teste967848 em domain.com'));
> +------------------------+
> | email                  |
> +------------------------+
> | teste967848 em domain.com |
> +------------------------+
> 1 row in set (0.00 sec)
>
>
> Em 15/09/2013, às 16:44, Eden Cardim <eden em insoli.de> escreveu:
>
> >>>>>> "Lucas" == Lucas Mateus <lucasmateus.oliveira em gmail.com> writes:
> >
> >    Lucas>     Show Eden, mas seu teste não tem absolutamente nada a
> >    Lucas> ver com o que eu disse =)
> >
> > A única diferença do que você mostrou é que no meu caso, o campo
> > email_md5 não existe porque não precisa, o índice resolve. E eu
> > coloquei valores md5 no campo email pra ter alguma aleatoriedade no
> > teste.
> >
> > --
> > Eden Cardim -- Insolide Soluções de TI Ltda.
> > +55 11 9644 8225
> > http://insoli.de
> > =begin disclaimer
> >   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> > SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
> > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> > =end disclaimer
>
> =begin disclaimer
>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>



-- 
Leonardo Ruoso
Journalist, Perl developer and business consultant
Media, UFC/2006; Telecom, IFCE/1998
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20130915/19103c6e/attachment-0001.html>