Li as respostas dos colegas, e não fui tão claro por não dar os campos da tabela, vou simplifica-la:
ID - Campo serial e chave primaria 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. Data - Data do jogo Hora - Hora do jogo Adversario - Id da tabela Outras Equipes - chave referencial etc... Com a ideia do novo campo (Jogo_Adversario), o negocio vai ser criar uma Stored Procedure mesmo, para popular o campo Jogo_Numero (todos os jogos), e Jogo_Adversario contagem dos jogos daquele Adversario. O ideal é montar uma stored procedure, e criar uma rotina para fazer isto, correto?? 2008/5/24 Marcus Fernandez <[EMAIL PROTECTED]>: > Desculpem enviar outra mensagem tão em seguida assim, mas percebi que posso > ter cometido um erro no meu comentário (mais uma vez desculpe-me por não ter > reparado no erro antes). Como esse número de jogo pode ser preenchido > incorretamente e necessite de posterior edição, não seria legal ter uma > chave primária que possa ser editada. Use esse campo como chave única e crie > um outro campo para ser primary key. > > Ainda assim eu acho a idéia da sequence legal para auxiliar o preenchimento > desse campo para os jogos futuros. > > Abraços, > Marcus Fernandez > > 2008/5/24 Marcus Fernandez <[EMAIL PROTECTED]>: > > Eu criaria uma sequence com start a partir do primeiro jogo (próximo jogo >> do SP) a ser cadastrado no sistema. Você poderá exibir na tela de cadastro >> de jogos o último jogo (se o último jogo foi o jogo 1200, exibira 1200 >> apenas para conhecimento). Caso o cliente queira cadastrar jogos passados, >> ou seja, de números anteriores, você libera o campo para preenchimento e no >> cadastro do sistema ao invés de pegar o valor da sequence, você simplesmente >> cadastra com o que foi determinado pelo usuário, lembrando que esse campo >> deve ser uma chave primária pois trata-se de uma chave natural, não >> existindo mais que um jogo de número 2 por exemplo. >> >> Precisar de uma mão é só chamar. Flw. >> Marcus Fernandez >> >> 2008/5/24 Leandro DUTRA <[EMAIL PROTECTED]>: >> >> 2008/5/23 Nilson Chagas <[EMAIL PROTECTED]>: >>> > Preciso ter um campo que vai ser o numero do jogo, ou seja jogo do SP >>> numero >>> > tal. >>> > >>> > Não pode ser um campo simplesmente sequencial, pq vai ter >>> colaboradores, >>> > lançando os jogos atuais, e outros lançando os primeiros jogos. >>> > >>> > Estava pensando em montar uma storeprocedure, que seria chamado de >>> quando em >>> > quando para ele recontar os jogos em ordem de data. >>> >>> Parece estranho. >>> >>> Na recontagem o número do jogo vai poder mudar? >>> >>> Caso contrário, sugiro que seja um número seqüencial sim, chave >>> candidata (alternativa ou primária), mas sob controle humano. >>> >>> -- >>> 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 > >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
