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 < [email protected]> 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 = '[email protected]'; > +------------------------+ > | email | > +------------------------+ > | [email protected] | > +------------------------+ > 1 row in set (0.21 sec) > > mysql> select email from users_2 where email_md5 = unhex(md5(' > [email protected]')); > +------------------------+ > | email | > +------------------------+ > | [email protected] | > +------------------------+ > 1 row in set (0.00 sec) > > > Em 15/09/2013, às 16:44, Eden Cardim <[email protected]> escreveu: > > >>>>>> "Lucas" == Lucas Mateus <[email protected]> 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: [email protected] > > 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: [email protected] > 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
=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
