2011/5/26 ivo nascimento <[email protected]>: > > Em 25 de maio de 2011 23:51, Leandro DUTRA <[email protected]> > escreveu: >> >> 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
Não entendi. Na mensagem anterior, e na seguinte, expressas opinião diametralmente oposta à minha: digo que chaves artificiais são para serem usadas para desempenho, estritamente quando necessárias, e tu dizes que devem ser usadas sempre, e as naturais declaradas somente quando necessário (que seria sempre, mas enfim…). Certo? > e afora casos onde as regras de > negócio definam que ou aquele "dado natural"(chave escolhida) é exigencia > para se existir no sistema Se não existe uma regra de negócio de unicidade, a análise de sistemas nem começou de fato: limitou-se a ‘impressões‘ sobre o sistema… Explico: chave artificial não garante unicidade no modelo lógico, só identifica um registro no modelo físico. Veja que chamei de registro e não de tupla, porque uma tabela sem chave natural não é uma relação, mas um saco, exatamente por aceitar duplicados. > ou se tenha certeza de que o objeto que esta > sendo administrado sempre tem tal dado Veja o que eu dizia, que o uso indiscriminado de chaves artificiais tende a deixar o modelo opaco: se há alguma ocorrência sem os dados das chaves naturais, temos um típico problema de normalização. Defrontamos não uma, mas duas entidades, incorretamente misturadas na mesma tabela, que portanto não é uma relação (impossível garantir unicidade). > fica estranho utiliza-lo como indice Ivo, confundes os níveis lógico e físico de modelagem. Não surpreende, portanto, a dificuldade em entender os conceitos e usos de chaves naturais e artificiais: não te está claro sequer o conceito de chave. Chave natural garante unicidade no modelo lógico. índice é uma ferramenta para melhorar desempenho no nível físico. Chave artificial é um complemento físico a uma chave natural complexa, exposta no modelo lógico apenas por limitação arbitrária do SQL. Chaves podem ser declaradas sem índice, a criação automática de um índice para cada chave é uma particularidade do SQL; índices não garantem unicidade, a não ser como índices únicos em suporte a uma chave natural. Isso me fez pensar numa pergunta aos universitários: ¿há alguma idéia ou projeto de implementação de chaves artificiais restritas ao modelo físico, quer no Postgres, nalgum outro sistema SQL, ou mesmo nalgum projeto de implementação de D em geral ou Tutorial D em particular? > mesmo por que regras de negócio mudam e pode surgir uma que faça, Quando mudam as regras de negócio, o modelo de dados tem de mudar. Se não mudar, é porque o modelo não garante consistência dos dados e, além disso, provavelmente escalará mal e (ou) somente com muito custo de manutenção de aplicações. > Por isso sempre opto por chaves artificiais(serial, big) etc. Complementarmente ou em substituição às chaves naturais? Se complementarmente, teu problema será somente ter limitado a escalabilidade do sistema e diminuído seu desempenho e transparência. Se em substituição, teu modelo simplesmente não é íntegro nem consistente. > 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? Não. Elas foram criadas por uma necessidade de negócio: dar um código de fácil transmissão, manipulação e memorização a uma entidade com chaves naturais complexas, independente da informatização. Esses códigos são chaves naturais alternativas, porque existem antes da modelagem dos dados. As chaves artificiais são criadas por motivos de desempenho, e deveriam ficar ocultas no modelo físico, sem aparecer no modelo lógico. Somente DBAs, SysAdmins, SGBDs, SOs e utilitários de sistema deveriam ver chaves artificiais, nunca ADs, programadores ou usuários, nem ferramentas de modelagem nem programas aplicativos. Não sei qual a taxonomia relevante na teoria, se é que há, mas eu chamaria esses códigos de chaves naturais sintéticas. Em comum com as chaves artificiais elas têm o fato de que não garantem unicidade se não estiverem relacionadas univocamente às respectivas chaves naturais. Aliás, relendo minhas mensagens anteriores, vi que minhas explicações anteriores não foram precisas neste ponto. Perdão. > 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. ¿Dá para decidir? ;-) > 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. Esse é um problema de análise de sistema, não de modelagem. O que for regra de negócio, o modelo tem de implementar. Por exemplo, pode-se criar uma categoria à parte de pessoa — p.ex., pessoa natural em contraposição à econômica, empresa informal versus legalizada, produto artesanal (?), livro de venda restrita… Eu proporia que essas categorias sem os ‘códigos sintéticos’ fossem as entidades genéricas, das quais as pessoas econômicas (com CPF), empresas formais (com CNPJ) &c fossem subtipos. >> 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. Não conheço os personagens. ¿É porque não tenho televisão? > 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? Aconteceria que o negócio seria realizado manualmente, sem o sistema, que teria de ser alterado a posteriori. ¿Ou alguém é louco de matar a contingência manual quando implementa o sistema informatizado? Sei, sei, de médico e de louco… > Quanto se trata de Regras de negócio, temos um cenário mutável, ao sabor das > necessidades. Por isso mesmo temos a teoria relacional, que permite alterar o modelo lógico com o mínimo essencial de alterações nos aplicativos. A alternativa é criar esses buracos, que inevitavelmente levarão, por um lado, a dados inconsistentes e, portanto intratáveis, levando até à instabilidade do aplicativos e inutilidade dos dados (vide Dilbert apud Euler); e, de outro, à implementação de regras nos aplicativos, que tornam-se excessivamente complexos, e portanto gargalos de desempenho, defeituosos e de manutenção custosa. Como sói acontecer. > 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=":?" Mas esse é um problema de linguagem de programação definida sem aprender as lições de meio século atrás — 52 anos, para ser preciso, que é a idade do Cobol. Não é um problema de modelagem de dados. Em Cobol, e noutras linguagens derivadas como Easytrieve+, pode-se simplesmente fazer chave-composta como um apelido para a estrutura da chave como um todo. Aliás, talvez seja esse tipo de limitação das linguagens ‘modernas’ que tenha limitado o interesse em manter as chaves artificiais restritas ao modelo físico, como deveria ser. >> 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) É relativo porque desempenho é sempre relativo não somente ao modelo, como à massa de dados e ao uso que se faz da mesma. Por exemplo, como nunca podemos deixar de declarar ao menos uma chave natural (composta ou não), o índice serial sempre será um índice a mais que terá de ser gerado, armazenado, atualizado e mantido em memória. Tudo isso tem custo. Sem contar que, em muitas relações relativamente pequenas, esses índices nem sequer serão usados. Por exemplo, numa relação pequena mas freqüentemente atualizada, um índice artificial poderia facilmente se tornar o gargalo de um sistema muito maior. > 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.... Não entendi, talvez por andar afastado da programação. Pode explicar? > 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". Ah, como é confortável trabalhar com a ‘lei’ de Moore… >> 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. Exato, mas percebe que não é o caso geral? Para que criar uma chave artificial quando a natural já for simples, ou quando simplesmente não for exportada como estrangeira, ou quando a exportação não gerar multiplicação suficiente para ser relevante para o desempenho do sistema? Seria otimização precoce, o que equivale a dizer, contraproducente, ou seja, otimização nenhuma, mera criação arbitrária de gargalos… >> 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. Como assim outro problema? A disciplina de usar chaves naturais por padrão e artificiais somente quando necessário é um garante de que o sistema não fará mais trabalho do que o necessário. Pensando bem, chaves naturais são até ecológicas. Seria legal verificar a ‘pegada de carbono’ das chaves artificiais generalizadas, em particular; dos maus modelos, em geral; e até da má arquitetura de sistemas, em última instância. Já pensaram, qual a pegada de carbono do MS Windows em contraposição a sistemas Posix, proprietários versus livres, C versus Lisp, Unix versus Plan 9… ¡é de dar nó na cabeça! -- 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
