Perdão se tiver entendido errado algo, tive dificuldades em entender o que escreveste.
2011/5/25 ivo nascimento <[email protected]>: > > Eu discordo: Primeiro por que a ideia de modelo opaco por que a frase > "chave artificial" não me convem. Essa não é uma afirmação objetiva, certo? > O fato de um dado não existir previamente nos dados de negócio não > significa ser artificial Não estou avaliando moralmente a artificialidade. É apenas o nome técnico de uma chave criada, não designada, originalmente por motivo de desempenho e para não aparecer no modelo lógico. Aparece por limitação do SQL, que não permite escondê-la no modelo físico. Na verdade, não tenho nada contra chaves artificiais — desde que usadas estritamente quando necessário, não sempre. > CPF e CNPJ são dados artificiais Pela definição técnica, não são artificiais. A ‘artificialidade’ duma chave refere-se a ter sido criada para o modelo físico ou existir fora do modelo. > sob os quais se aplicam regras para garantir integridade > "chave primaria". Não entendi. > mas eu tenho que concordar com a questão de opaco, mas que solução a > receita federal teria, que dado ela trabalharia correto? E trabalha. Existem chaves naturais, sempre, até para o RG que é ainda mais genérico e bagunçado. Só que, por serem grandes, os órgãos em questão criam esses códigos, que ao serem externalizados tornam-se naturais, ao menos para os outros, ou seja, todos nós. > 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? Isso é uma definição de negócio, não de modelagem. > ou, rapidamente surgira um "numero de documento"? Não entendi o ponto. Aliás, como pode surgir um número de documento… sem 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 Não necessariamente. Até na vilificada Cobol era fácil resolver isso. > e dá mais trabalho de indexação do que um serial. Isso é relativo. > 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 Teu uso da palavra ‘talvez’ diz tudo. Otimização precoce é a raiz de toda sorte de males. Mas o erro é mais fundamental ainda. O uso de uma chave artificial não dispensa a declaração da(s) chave(s) natural(is). Se dispensar, é um desastre de consistência e documentação; se não dispensar, engordou o modelo, consome mais disco, mais cache… > e isso seria o inicio de um efeito cascata quando essa > mesma chave tiver de ser usada como estrangeira em outras tabelas Essa é a situação para a qual foi criado o conceito de chave artificial. Mas está longe de ser o caso geral. > 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. Só que, muitas vezes, o dado que se quer trazer da outra tabela seria justamente a chave natural, exportada como estrangeira. Cansei de ver isso na prática. > 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. Não entendi, talvez por cansaço. -- 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
