Em 15 de setembro de 2013 21:28, Leonardo Ruoso <[email protected]>escreveu:
> 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 :) > > Acho esta afirmação parcialmente verdadeira. Conhecer que existe um email na tua base é inevitável quando vc a está utilizando como uma chave para o sistema, e nem preciso ser um hacker para isto. Qualquer um pode saber quais são os emails que estão cadastrado no Amazon.com e no Twitter, por exemplo, mas isto não é considerado uma falha de segurança da Amazon. > > > 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 > > -- "o animal satisfeito dorme". - Guimarães Rosa
=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
