Em 25 de maio de 2011 19:26, Leandro DUTRA <[email protected]>escreveu:
> 2011/5/25 ivo nascimento <[email protected]>: > > eu realmente acho que, apesar de alguns atributos reais serem fortes o > > suficiente para serem utilizados como primary key, é sempre mais > > interessante utilizar como chave um serial. > > Não. A chave artificial engorda o modelo e o torna mais opaco, além > de forçar junções desnecessárias. > Eu discordo: Primeiro por que a ideia de modelo opaco por que a frase "chave artificial" não me convem. O fato de um dado não existir previamente nos dados de negócio não significa ser artificial e tampouco o contrario é verdadeiro. CPF e CNPJ são dados artificiais sob os quais se aplicam regras para garantir integridade "chave primaria". mas eu tenho que concordar com a questão de opaco, mas que solução a receita federal teria, que dado ela trabalharia correto? A mesma coisa se aplica ao raciocinio da aplicação. Se voce estabelecer, por exemplo, que um sistema de emprestimos tera como das pessoas o CPF e entrar um mendigo, sem CPF, querendo fazer uma aplicação ele sera barrado pela questão de que ele não tem um documento sem o qual o sistema não funciona? ou, rapidamente surgira um "numero de documento"? Afora que trabalhar com chaves desse tipo, ou pior, tomar valores reais na composição de chaves compostas dificulta a lida desse modelo quanto portado para a programação e dá mais trabalho de indexação do que um serial. Por exemplo, levando em conta que use um domain com o tipo de dado char(11), ao inves de um bigint, talvez existam mais páginas de indice por que a entrada do indice é maior, e isso seria o inicio de um efeito cascata quando essa mesma chave tiver de ser usada como estrangeira em outras tabelas, o que me leva a ultima parte da sua frase, de juncoes desnecessarias. Não vejo como o uso das chamadas "chaves reais" vai melhorar a questão de junções. Se eu tenho uma chave e preciso buscar um dado em outra tabela, para traze-lo eu devo ou inserir a requisição dos dados na mesma query ou fazer uma nova requisição usando a chave como parametro. Muito bem suposto o comportamento de que uma chave primaria, quando utilizada em outra tabela, digamos, 1:1, vai provavelmente estar na mesma página de indice (?) e isso seria interessante para acelerar a recuperação dos dados, e isso vai de encontro com as informações que estão presentes no catalogo do sistema sobre os indices, que irão acelerar a busca. Esse é meu ponto de vista para este caso. > > > > > Em 25 de maio de 2011 17:59, Flavio Henrique Araque Gurgel > > <[email protected]> escreveu: > >> > >> Usar o nome como PK e usar pra relacionamento não vai dar muito certo. > > Não necessariamente. > > > -- > skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (61) 3546 7191 gTalk: xmpp:[email protected] > +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 > BRAZIL GMT-3 MSN: msnim:[email protected] > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Ivo Nascimento - Iann ------------------------------------------------- http://about.me/ivonascimento -------------------------------------------------
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
