Muito obrigado por tua mensagem, Adami! Gostei muito do exemplo e de como o explanaste.
Só algumas pequenas observações, que nada deslustram: 2016-08-25 14:17 GMT-03:00 Tiago José Adami <adam...@gmail.com>: > > E eu avalizo totalmente esta declaração. E ainda quero citar um > exemplo do porquê chaves naturais compostas DEVEM ser utilizadas > sempre que possível. Eu diria que *sempre* _têm_ de ser utilizadas. Se não for possível, é erro de modelagem, provavelmente de compreensão ou do modelo relacional. Especificamente, se for necessário pode-se definir uma chave artificial *além* das naturais. > Como exemplo à declaração do Dutra, a tabela RESERVA_ITEM_AUTORIZACAO > possui 7 campos em sua chave primária, todos naturais que são todos os > campos da tabela. Ou seja, é uma tabela onde todos os campos são parte > da chave primária, sendo uma tabela "clássica" de relacionamento N*N. Sim, no n:n por definição todos os atributos participam da chave, que no caso é sempre composta e única (não há chaves alternativas). Mas referi-me a uma situação um pouco diferente: há casos em que há dificuldades de se obter uma chave natural que realmente garanta unicidade. Por exemplo, o RG, para as SSPs, é uma chave artificial; a natural é nome completo, filiação, data e local de nascimento… e há casos de duplicação dos atributos que acabo de listar, por incrível que pareça: por exemplo, dois homens, se não me engano nascidos no interior da BA, que tinham o mesmo nome, que nasceram no mesmo dia e cidade, e cujos mãe e pais também tinham nomes idênticos. Num caso desses, a saída é incorporar mais informações ao modelo. Não sei o que a SSP/BA fez nesse caso, nem o que as SSPs em geral fazem, mas o óbvio seria incorporar alguma informação adicional: como exemplos meio idiotas, só mesmo a título de exemplo, identificação da certidão de nascimento, ou hora de nascimento, ou nomes dos avós… Outro exemplo é uma tabela armazenando um registro de atividades (trilha de auditoria). Pode ser necessário colocar todos os atributos do /log/ como chave, e no limite até incorporar um contador para o caso em que no mesmo momento a mesmíssima mensagem apareceu várias vezes. Mas, geralmente, um TIMESTAMP resolve um caso desses. > Finalizando minha "história", com exceção de um índice único e 2 > TRIGGERs para tratar horários conflitantes, toda a integridade lógica > ficou GARANTIDA apenas pelo uso das FK's e PK's com atributos > naturais, mesmo que com vários campos. E o número de FK's foi reduzido > para 1 terço do que havia antes, pois a propagação das chaves > compostas garante a integridade com a tabela "pai" de todos os níveis > superiores. E imagino que tanto desempenho quanto carga de máquina e de rede, usabilidade e manutenção melhorem muito. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
