[SP-pm] DBIx::Class

[Leonardo Ruoso]

2013/9/22 Luis Motta Campos <luismottacampos em yahoo.co.uk>

> On 18 Sep 2013, at 14:01, Solli Honorio <shonorio em gmail.com> wrote:
> > "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:†"
> 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.
>

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 é:

1) Use chaves compostas o tempo todo;
2) Use chaves naturais sempre que possível;

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):

country (id PRIMARY KEY, code, name)
state (id PRIMARY KEY, code, name, country_id)
municipality (id PRIMARY KEY, code, name, state_id)
street (id PRIMARY KEY, name, municipality_id)

Eu faria, hoje, assim em algumas situações:

country (id, geocode, name, PRIMARY KEY(id))
state (country_id, id, geocode, name, PRIMARY KEY(country_id, id) )
municipality (country_Id, state_id, id, geocode, name, PRIMARY
KEY(country_id, state_id, id))
street (country_id, state_id, municipality_id, id, geocode, name,
disambiguation, PRIMARY KEY(country_id, state_id, municipality_id, id))

Os ID seriam algo como $id = &uri_alphanum_or_hifen($name . ' -'.
$disambinguagion)




-- 
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/20130922/d35a25c7/attachment.html>