2008/11/14 Rogério A Bassete <[EMAIL PROTECTED]>: > > Estou lhe escrevendo por que assisti sua palestra no último evento PGCON > 2008 na UNICAMP. [...] Somente agora pude estudar mais detalhadamente o > conteúdo dela e vou lhe fazer algumas perguntas, e já lhe adianto para > sentir-se livre a responde-las ou não.
Rogério, estou direcionando a sua resposta à lista pgbr-geral, onde todos esses assuntos são discutidos. Procure sempre fazê-lo; enquanto não tenho tempo para respostas individuais, e até tenho afastado da lista, é mais fácil justificar um debate comunitário, que beneficia a todos, que uma resposta individual. Procure continuar a discussão na lista, não em particular. > Simples tabela para armazenar dados de pessoas: > > CREATE TABLE pessoa ( > id SERIAL NOT NULL, > nome VARCHAR(50) NOT NULL, > cnpj VARCHAR(14) NOT NULL, > inscricao_estadual VARCHAR(20) NOT NULL, > endereco VARCHAR(40) NOT NULL, > telefone VARCHAR(10), > cadastro DATE > ) > > 1. Devo criar chave única para todos os campos que não podem ter linhas > duplicadas na tabela, exemplo: CNPJ, NOME, CNPJ, IE ou usar o bom senso? Bom, antes de mais nada, você tem certeza que nome não pode ser duplicado? Ou que todos terão CNPJ, e o CNPJ não será duplicado? Recentemente alguém trouxe a esta lista a informação de que, em determinada unidade da Federação, todas as escolas estaduais compartilhavam um mesmo CNPJ... E o que seria 'bom senso' para você? É um conceito inteiramente subjetivo. O que há de objetivo é que toda relação (tabela) precisa de ao menos uma chave natural, para evitar eventuais duplicados — o que implica também em poder identificar qualquer tupla (registro). Só você pode dizer quais seriam as chaves candidatas. Em última instância, poderia ser necessária uma chave constituída de todos os atributos naturais (ou seja, excluindo seu id SERIAL) e requeridos (NOT NULL). Dependendo do que você está modelando, CNPJ (ou, no exemplo acima, CNPJ e endereço) poderia ser uma chave suficiente. > Simples tabela de tipo de produto: > > CREATE TABLE tipo_produto ( > id SERIAL, > descricao VARCHAR(20) > ) > > 2. Você disse que devemos evitar os famosos campos ID autonumerado e sim > utilizar uma chave natural, mas e no caso da tabela hipotética tipo_produto > que possue um campo VARCHAR como chave natural, mesmo assim você não criaria > um campo SERIAL para facilitar relacionamentos? Em que facilitaria, se o atributo (campo) caracter (VARCHAR) já é identificação suficiente? A diferença de desempenho geralmente não é relevante, e pode ser até mais do que contrabalançada pela necessidade de um índice adicional, pela relação ser mais gorda &c. Agora, se o usuário quer ter um código, aí seu id deixa de ser um identificador artificial e passa a ser aceitável, porque será usado pelo usuário. Mas ainda assim seria necessário ter uma chave alternativa sobre o atributo caracter, para evitar duplicação de dados. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7344 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
