Olha um amigo já falow certa vez, a escrita não expõe a tonalidade das palavras.
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. E estou fazendo de uma equipe especifica, porque é um trabalho direcionado para uma equipe especifica. E sou humilde o suficiente para admitir que não entendi como um campo sequencial e chave primaria permite duplicações??? Os dois campos citados, Jogo_Numero e Jogo_Adversario, não podem ser chaves, e nem tem como eu saber porque haverá pessoas lançando os jogos de epocas diferentes. Sim, o SP já jogou duas vezes no mesmo dia. Coisas de futebol. Eu tenho varios outros indices, na busca de uma melhor otimização nas consultas. E desculpe por alguma coisa. []s Nilson 2008/5/25 Leandro DUTRA <[EMAIL PROTECTED]>: > 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]<[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 >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
