2 coisas que faltaram dizer: a) o mendigo acabou de ganhar 10 milhoes na loteria b) não podemos deixar de lembrar da questão de encoding, tamanhos em byte do char e etc.
Em 25 de maio de 2011 22:40, ivo nascimento <[email protected]> escreveu: > > > 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 > ------------------------------------------------- > > -- Ivo Nascimento - Iann ------------------------------------------------- http://about.me/ivonascimento -------------------------------------------------
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
