Como guardar nºs das extrações do Euromilhões?

[naoliveira]

boas ppl,

estou a pensar fazer um programa sobre o Euromilhões, mas gostaria de saber a vossa opinião sobre a melhor maneira de guardar os nºs saídos em cada extração, primeiro como distinguir os nºs das estrelas, depois o melhor método para mais tarde fazer estatísticas.

Para distinguir os nºs das estrelas estava a pensar em guardar as estrelas como 101 ... 109, será que existe um método melhor?
Para as estatísticas defino uma tabela com índice, data extração, posição, nº. O meu objectivo é mais tarde conseguir dizer quantas vezes um nº saiu e indo mais longe quantas vezes saiu em determinada posição, tendo os nºs todos na mesma coluna isso será mais fácil ou não? só tenho de procurar pelo critério que quero nas outras colunas, ex: nº 45 quantas vezes saiu -> um Count normal, 45 quantas vezes saiu na posição 3 -> Count com a coluna posição = 3 e nº = 45, and so on.

Gostava de 'ouvir' a vossa opinião.

 

[mj2p]

boas ppl,

estou a pensar fazer um programa sobre o Euromilhões, mas gostaria de saber a vossa opinião sobre a melhor maneira de guardar os nºs saídos em cada extração, primeiro como distinguir os nºs das estrelas, depois o melhor método para mais tarde fazer estatísticas.

Para distinguir os nºs das estrelas estava a pensar em guardar as estrelas como 101 ... 109, será que existe um método melhor?
Para as estatísticas defino uma tabela com índice, data extração, posição, nº. O meu objectivo é mais tarde conseguir dizer quantas vezes um nº saiu e indo mais longe quantas vezes saiu em determinada posição, tendo os nºs todos na mesma coluna isso será mais fácil ou não? só tenho de procurar pelo critério que quero nas outras colunas, ex: nº 45 quantas vezes saiu -> um Count normal, 45 quantas vezes saiu na posição 3 -> Count com a coluna posição = 3 e nº = 45, and so on.

Gostava de 'ouvir' a vossa opinião.

Estás a usar que SGBDR (Sistema Gestor de Base de Dados Relacional)? MySQL ou outro?

Bem, eu acho que este caso nem se quer requer grande ginástica em termos de base de dados. Uma tabela com o nome sorteio, em que tivesses uma chave primária para depois identificares o sorteio e depois uma coluna para cada numero e outras duas para as estrelas. Acho que não é preciso compicar o que é fácil.

Vá, cumps

 

[naoliveira]

O SGBDR é indiferente mas em princípio vai ser MSSQL. Como tu dizes é mais fácil para gravar os dados na tabela, mas por exemplo para as estatísticas, quantas vezes um nº saiu? tenho de fazer um count para cada coluna com os nºs e depois somar, se for para saber quantas vezes saiu num determinda posição como dizes é mais fácil. Tenho de ver bem o tipo de estatísticas que vou fazer para depois optar.

 

[mOrSa]

Olá! O que tens interesse é guardar os valores e pela ordem que saíram e não pela ordem "correcta" ascendente dos mesmo.
Eu propunha a seguinte estrutura para a tabela:

edit2:
Extracao (NumSorteio, Numero1, Numero2, Numero3, Numero4, Numero5, Numero6, Estrela1, Estrela2, Data)

[ NumSorteio e Ano são as primary key's ]

A partir daqui acho que é pacífico obter quaisquer tipo de estatísticas que precises. O correcto, do ponto de vista normativo, não seria o que está em cima mas sim duas tabelas. De qualquer forma nunca irás ter valores nulos o que colmatará uma das falhas.
Todavia, com a pesquisa feita numa só tabela há um aumento de performance na query por isso eu utilizava essa estrutura.

1abraço!

edit: SGBDR (Sistema Gestor de Base de Dados Relacional) <- isto parece-me mto PT-BR e desculpem os colegas do Brasil. Eu chamo Sistema de Gestão de Base de Dados, SGBD portanto.

 

[mj2p]

Olá! O que tens interesse é guardar os valores e pela ordem que saíram e não pela ordem "correcta" ascendente dos mesmo.
Eu propunha a seguinte estrutura para a tabela:

Extracao (NumSorteio, Ano, Numero1, Numero2, Numero3, Numero4, Numero5, Numero6, Estrela1, Estrela2, Data)

[ NumSorteio e Ano são as primary key's ]

A partir daqui acho que é pacífico obter quaisquer tipo de estatísticas que precises. O correcto, do ponto de vista normativo, não seria o que está em cima mas sim duas tabelas. De qualquer forma nunca irás ter valores nulos o que colmatará uma das falhas.
Todavia, com a pesquisa feita numa só tabela há um aumento de performance na query por isso eu utilizava essa estrutura.

1abraço!

edit: SGBDR (Sistema Gestor de Base de Dados Relacional) <- isto parece-me mto PT-BR e desculpem os colegas do Brasil. Eu chamo Sistema de Gestão de Base de Dados, SGBD portanto.

A tabela que o mOrSa propos era exactamente aquilo em que eu estava a pensar. Só acho que poderia reduzir-se a chave primária a NumSorteio, sendo ano uma informação adicional. Mas tudo bem.

Quanto ao teu edit, quando me quero referir a este termo até uso a terminologia inglesa, RDBMS (Relational Data Base Managment System). Quando eu digo relacional, estou-me a referir especificamente a um sistema gestor de base de dados que o utilize especificamente o método relacional, e não outro, como por exemplo o sistema de orientação a objectos (apesar de ainda ser um sistema pouco usual).

Se quisermos falar de normalidades, então até se poderia optar por criar uma tabela sorteio e outra numeros. Mas pensando neste caso, a um sorteio estão associados vários numeros (7 mais precisamente) mas a um numero também estão associados mais que sorteios (o numero 35, por exemplo, pode sair em mais que um sorteio). Deste modo, terias de decompor a relacção entre estas duas entidades (que seria do tipo M:N) em duas do tipo 1:N, através da criação de uma nova entidade, que poderia ser chamada "Sorteio_detalhes". Esta entidade tomaria como chave primária o conjunto da chave primária de "Sorteio" e a chave primária de "Numeros".

Quando se está a implementar uma base de dados, é muito frequente ter-se de dividir uma relação do tipo M:N. Mas isto é quando não se sabe qual o numero de ocorrencias de uma relação para a outra. Neste caso, sabe-se que um sorteio corresponderão sempre 7 numeros, logo não há necessidade de tanto trabalho.

Vá, cumps

 

[tripeiro]

entao e hashtables? ou nao usas isso?
ai ja seria um programa se calhar mais dificil de fazer...

isso numa bd parece-me muito complicado, ou entao estou a ver mal...

 

[mOrSa]

errr... num era numero do sorteio mas sim número da semana. LOL hj n tou nada bem!
Primeiramente lembrei-me da semana/ano mas depois lembrei-me que tinha um n.º de sorteio. Logo... -> numero do sorteio como PK somente.

Hashtables? com que intuito?

1abraço!

 

[CyberOps]

entao e hashtables? ou nao usas isso?
ai ja seria um programa se calhar mais dificil de fazer...

isso numa bd parece-me muito complicado, ou entao estou a ver mal...

hastables para procuras de chaves em tempo reduzido compensava, mas se calhar aqui o objectivo é fazer estimativas dos numeros que sairam ao longo dos tempos, logo arraylists é o mais indicado

 

[naoliveira]

Ok, obrigado pela vossa colaboração, mas em relação ao modo como eu estava a pensar fazer, apenas uma coluna para os nºs e outra que indica a sua posição o que acham? A mim parece-me melhor para fazer as pesquisas.

Em relação às hashtables, vou pesquisar um bocado para ver o que isso é e se pode ajudar ou não.