2008/5/25 Nilson Chagas <[EMAIL PROTECTED]>: > Olha um amigo já falow certa vez, a escrita não expõe a tonalidade das > palavras.
Então tudo bem, vamos tocar o barco! ;-) Realmente é difícil escrever bem no Brasil hoje, há pouco descobri que não me ensinaram a escrever direito — isso sendo filho de professores de português. > Não quis ser mal-criado ou pré-conceituoso, e citei o DBA em Oracle da > empresa, veja que foi muito especifico, que é justamente professor de > modelagem de dados e engenharia de software. Em resposta ao fato de você ter > pedido para procurar um administrador de dados. Bom, então por que você pede nossa ajuda? E em que ele contradiz o que estou aconselhando? Já adiantando que conheço até professor da USP ensinando, em livro, a transformar o que deveria ser uma exceção devida a limitações físicas do SQL como se fosse melhor prática. > E sou humilde o suficiente para admitir que não entendi como um campo > sequencial e chave primaria permite duplicações??? Simples. Imagine que você tenha uma chave primária campo serial (que na verdade é um campo numérico inteiro definido com DEFAULT buscando de uma seqüência automaticamente). Você pode incluir o mesmo jogo quantas vezes quiser, e o sistema vai aceitar — simplesmente vai dar um identificador diferente para a mesmo jogo a cada inclusão. Por isso a regra é: só use uma chave artificial se realmente necessário, e mesmo assim declare pelo menos uma outra chave natural. > Os dois campos citados, Jogo_Numero e Jogo_Adversario, não podem ser chaves Acho que você não entendeu: não seriam duas chaves, mas uma chave composta. > e nem tem como eu saber porque haverá pessoas lançando os jogos de epocas > diferentes. Isso independe de você saber, a base de dados tem de garantir a integridade independente de quantas pessoas estiverem fazendo o que for. > Sim, o SP já jogou duas vezes no mesmo dia. Coisas de futebol. Legal, então uma eventual chave deve incluir pelo menos a hora. > Eu tenho varios outros indices, na busca de uma melhor otimização nas > consultas. Não misture os conceitos lógicos e físicos. Estamos discutindo o modelo lógico aqui, que lida com chaves; índices são meramente físicos, não mudam nada no modelo lógico. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED] _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
