Está a tornar-se interessante esta discussão...
Sem mais demoras vou levantar mais um pouco a ponta do véu acerca da aplicação que usará essas tabelas.
Irão existir de facto apenas 2 tabelas:
- a dos utilizadores e todos os seus dados
- a do registo de ganhos
Porque não uma terceira com os ganhos a aprovar? Estes serão rastreados por outro site. Portanto o tamanho e até existência dessa terceira tabela não se coloca.
Adiante, a tabela dos ganhos apenas terá registados ganhos confrmados (aliás, manualmente confirmadíssimos), por isso, cada registo que lá for concatenado, já estará confirmado e não necessitará de alterações futuras (só em caso muito excepcionais que por agora não preconizo).
Mais, com php consigo perfeitamente extrair da linha dos ganhos de cada dia os dados que preciso. Por exemplo:
IDuser | data | timestamp1 - valor do ganho1 - tipo de ganho1 # timestamp2 - valor do ganho2 - tipo de ganho2...
Um user regista ganhos pela primeira vez num dia? Crio uma linha nesta tabela e no formato referido.
O user regista mais que um ganho no mesmo dia? Pesquiso se já há alguma linha criada no dia em causa e havendo concateno os dados ao 3º campo.
Para o user ver os ganhos desse dia, select à tabela para esse dia e retorno o resultado com ajuda de um "explode" e fazendo a soma dos ganhos. E tenho selects rápidos.
Para ver que ganhos foram registados pelo user num mês, Select outra vez e ...
Ou seja, parece-me viável esta estrutura e permite não só ter uma base de dados de tamanho "normal" como também permite ao user ter os dados á sua frente de forma rápida.Do lado do backoffice, não me parece que se levantem grandes problemas de gestão dos utilizadores e dos seus ganhos.
JTK o meu problema é já ter criado uma tabela que demorava "horas" a fazer selects para ver por exemplo os ganhos de um mês para cada utilizador, pois tinha a estrutura do tipo: IDuser | IDganho | hora | valor do ganho. Ou seja, para cada ganho tinha uma nova linha na tabela. Logo, tinha selects muito lentos e já para não falar que esta tabela com o tempo ficaría enorme.Daí que ache que esta estrutura proposta pelo Gonçalo seja a mais adequada para mim. Não quer dizer que em outros casos a tua proposta não seja boa. Mas, no meu caso e eu como ninguém sei aquilo que se adequa mais ao meu problema, penso ser esta a melhor solução.
Mas, estou aberto a soluções diferentes, ou não teria colocado este tópico em discussão
De novo, obrigado pela colaboração de todos.
PS: Do lado do backoffice, algo que queria preservar era a hora e até segundo exacto a que é registado um ganho e com este formato saberei sempre isso com a ajuda do timestamp e também saberei que tipo de ganho foi registado e o seu valor. Tudo no campo 3:
"timestamp1 - valor do ganho1 - tipo de ganho1".
Cumps
MM
