Em 25 de maio de 2011 23:51, Leandro DUTRA <[email protected]>escreveu:
> 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. > entendo. > > Na verdade, não tenho nada contra chaves artificiais — desde que > usadas estritamente quando necessário, não sempre. > exato... também penso da mesma maneira e afora casos onde as regras de negócio definam que ou aquele "dado natural"(chave escolhida) é exigencia para se existir no sistema ou se tenha certeza de que o objeto que esta sendo administrado sempre tem tal dado, fica estranho utiliza-lo como indice, mesmo por que regras de negócio mudam e pode surgir uma que faça, por exemplo, CPF não mais ser requisito para cadastrar alguém no sistema. Por isso sempre opto por chaves artificiais(serial, big) etc. > > > > 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. > pela definição tecnica voce esta correto, mas a de convir que ambos os dados são chaves criadas artificialmente mas que, devido a sua natureza de uso nacional, se tornaram naturais, correto? Assim como o uso de um EAN para um produto, ou de um ISBN para um livro, no momento em que esse numero é anexo ao objeto proprietario ele não mais troca (as vezes troca) de valor. Então seriam potenciais chaves primarias, mas fico com a pergunta de: O que fazer enquanto a pessoa não tem CPF, a empresa não tem CNPJ, o produto não tem EAN e o livro não tem ISBN. > > > > 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? > aqui vou dar uma de Leonard e levantar a plaquinha de sarcasmo ;) pq voce pareceu o Sheldon. Era exatamente isso que queria dizer. Se a regra de inserção de um cliente em um sistema se baseasse em uma chave natural e o valor para essa chave não existisse, mas mesmo assim o valor de negócio fosse enormemente tentador. O que aconteceria? Devo supor que as regras seriam alteradas(legalmente) ou a negociação seria postergada ate existir o devido dado natural. O que poderia levar a prejuízo ao negócio. Quanto se trata de Regras de negócio, temos um cenário mutável, ao sabor das necessidades. > > > > 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. > O que eu quis dizer aqui é que é muito mais simples trabalhar com chaves seriais como primary keys do que chaves compostas. Compor os dados para localização com chaves compostas é, no minimo, mais chato do que definir where id=":?" > > > > e dá mais trabalho de indexação do que um serial. > > Isso é relativo. > Não consigo ver relatividade nisso já que existem muito mais coisas a se organizar em um char do que em um Int. ordenar os numeros de 0 a 10 é um tarefa trivial perto de ordenar a lista de nomes de alunos em uma sala de aula de 10 alunos(não estou falando de mecanismos especializados de ordenação e pesquisa) > > > > 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. > concordo com a razão dos males, mas adiciono nesses males outro com o qual talvez me preocupe mais... a não definição de objeto para a otimização... sabe, aquele negócio de eterna otimização, mesmo que já com o objetivo alcançado.... 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… > isso eu concordo, e é uma coisa sobre a qual já parei para pensar algumas vezes, e ate o momento tenho que dizer que tenho preterido o modelo magro em favor do "gordo". > > > > 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 efeito cascata ao qual me referi é que aquela chave, com aquele tamanho de dados, vai se repetir inumeras vezes pelo sistema. > > > > 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. > hummm, mas ai é outro problema. > > > > 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 > -- Ivo Nascimento - Iann ------------------------------------------------- http://about.me/ivonascimento -------------------------------------------------
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
