<div dir="ltr">2013/9/22 Luis Motta Campos <span dir="ltr"><<a href="mailto:luismottacampos@yahoo.co.uk" target="_blank">luismottacampos@yahoo.co.uk</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On 18 Sep 2013, at 14:01, Solli Honorio <<a href="mailto:shonorio@gmail.com">shonorio@gmail.com</a>> wrote:<br>
<span style="color:rgb(34,34,34)">> "You should also be very careful with completely “random” strings, such as those produced by MD5( ), SHA1( ), orUUID( ). Each new value you generate with them will be distributed in arbitrary ways over a large space, which can slow INSERT and some types of SELECT queries:†"</span><br>
</div>
<div class="im"><span style="color:rgb(34,34,34)">Esta é também a minha opinião como DBA profissional de uma grande corporação de comércio eletrônico. Usar hash criptográfico para "melhorar" estatísticas de um índice é normalmente tiro de canhão para matar mosquinha, e mais frequentemente do que não sai pela culatra.</span></div>
</blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">Eu nem sou DBA, mas tenho tido alguma experiência com sistemas de vida razoávelmente longa (≥10 anos) que passam por gerações de desenvolvedores e de administradores e uma coisa que eu defendo hoje em dia é:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">1) Use chaves compostas o tempo todo;</div><div class="gmail_extra">2) Use chaves naturais sempre que possível;</div><div class="gmail_extra"><br></div><div class="gmail_extra">
Vou dar um exemplo, imagina que você tem um software cujo endereço seja formado por geocodes obtidos de PKEYS arbitrárias. Alguém poderia desenvolver algo assim, por favor, deduzam as referências estrangeiras e os id como inteiros sequenciais (nada melhor para os inserts):</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">country (id PRIMARY KEY, code, name)</div><div class="gmail_extra">state (id PRIMARY KEY, code, name, country_id)</div><div class="gmail_extra">municipality (id PRIMARY KEY, code, name, state_id)</div>
<div class="gmail_extra">street (id PRIMARY KEY, name, municipality_id)</div><div class="gmail_extra"><br></div>Eu faria, hoje, assim em algumas situações:</div><div class="gmail_extra"><div class="gmail_extra"><br></div>
<div class="gmail_extra">country (id, geocode, name, PRIMARY KEY(id))</div><div class="gmail_extra">state (country_id, id, geocode, name, PRIMARY KEY(country_id, id) )</div><div class="gmail_extra">municipality (country_Id, state_id, id, geocode, name, PRIMARY KEY(country_id, state_id, id))</div>
<div class="gmail_extra">street (country_id, state_id, municipality_id, id, geocode, name, disambiguation, PRIMARY KEY(country_id, state_id, municipality_id, id))</div><div><br></div></div><div class="gmail_extra">Os ID seriam algo como $id = &uri_alphanum_or_hifen($name . ' -'. $disambinguagion)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div><br></div>-- <br>Leonardo Ruoso<div>Journalist, Perl developer and business consultant<br>
<div>Media, UFC/2006; Telecom, IFCE/1998</div></div>
</div></div>