2008/5/24 Nilson Chagas <[EMAIL PROTECTED]>: > Olha, eu acho que vc não entendeu ou eu não soube explicar.
Talvez um pouco de cada um, afinal esse tipo de conselho é difícil de dar por correio eletrônico. Por isso a sugestão de uma consultoria dum AD. > Tenho um campo sequencial, para ficar mais facil, exclusão e alteração do > registro. Isso é um vício desnecessário. O que importa é ter uma ou mais chaves. Um campo seqüencial por definição é uma má chave, porque permite duplicados; embora possa ser necessário em várias circunstâncias, em se tratando de SQL. >> > Jogo_Numero - Seria o campo que conteria o numero do jogo. >> > Jogo_Adversario - Tive esta ideia depois de ter mandado a mensagem, >> > provavelmente nas estatistica vão querer sabe que é o jogo de numero tal >> > contra determinado adversario. […] > Usar o campos Jogo_Numero e Jogo_Adversario como chave?? Qual a razão > disto?? visto que ele é somente para um efeito visual e estatistica. Você mesmo disse que não é apenas visual: 'vão querer sabe que é o jogo de numero tal contra determinado adversario', ou seja, é uma forma de identificação do jogo. E uma chave é exatamente isso, uma forma de identificação do dado. > Você quer que eu exclua o campo Data?? De onde você tirou isso? Apenas estou supondo que seja outra chave candidata, uma vez que me parece que você trabalha com jogos dum único time e provavelmente um time não jogará mais de um jogo no mesmo dia. Caso jogue, precisa incluir hora também na chave. Entretanto, e aproveitando, me parece má modelagem dividir em um time principal e 'outros times'. > E eu realmente criei um indice, > logico que não unico, para uma eventual consulta. Por que lógico? > E eu não entendi o problema de se usar junções. Desempenho e complexidade. Principalmente complexidade. Todo dia quase pego consultas com três, quatro, cinco junções que podia ter apenas uma ou duas se o modelo usasse chaves naturais. > Se eu fosse guardar apenas o > nome da equipe adversaria tudo bem, mas não é o caso. Nada a ver, você pode ter outra tabela com os dados adicionais. O interessante é que, usando chaves naturais, simplifica-se o uso da base, e bastante. > E eu teria o campo > nome da equipe em duas tabelas??? Por que não? Realmente há casos em que não é desejável, mas seria o teu? > Realmente se for assim preciso de uma administrador de dados, e mandar o DBA > Oracle da empresa embora. Não necessariamente. Infelizmente, alguns DBAs hoje não estão qualificados para modelagem, mas ainda cumprem seu papel de cuidar do SGBD. Mas o que nossa discussão tem a ver com seu DBA Oracle? Vamos com calma. Você pediu ajuda em casos básicos, mas aparentemente não conhece o modelo relacional, a teoria da normalização e as implicações práticas. Se quer aprender, vamos conversar com calma; se não, se quer só confirmar teus (¿pré-?)conceitos, nem precisa recorrer à lista. -- 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
