Which database table design is better?

Question

Hi Experts,
I've a dilemma, my situation is like this: I'm planning to do a lottery analysis software in java. Basically it is just 10,000 digits namely 4D(digits) from 0000 to 9999. Database would store historical data from year 1990 to present with around a few thousand records. From here, I would need to analyse like which numbers belong to a total of certain numbers (like 1234 would be 10), and so on.
My real problem comes in here, do I store the analysis data together with the historical data? I tried and I would need many many columns like around hundreds of them (just the total analysis example above would need 36 columns and not to mentions tons of other analysis data). This type of design do not need any programming on the client side, just retrieval but I reckon it would pose a lot of problems in future in terms of scalability.
The second solution which I google and read in this forum is just store the historical data in one table and use another table to JUST store the analysis name. Heavy programming and algorithm would be needed on the client side but I'm worried about the processing speed since I'm not well-versed in many algorithm logics. I know this design is good since redundant data is eliminated but I simply have no idea how to link the historical and analysis table together.
Could any industry experts on database structure and algorithm guide me as I'm been scratching my head for a few days.
Many thanks in advance.

Answer 1

Sorry for the late reply. I have also thought of
putting all the analysis data into the database but
the data is simply too many and moreover requests
from the visitors could have differrent cominations
of analysis data which would make it almost
impossible to store all the differerent combinations
in database.
I am not sure I understand why this is a problem.
Say you had a lottery drawing every single day for the last 20 years. That means you would have 7300 records.
That is a trivial number for even small database.
Doing a query for sums to a single value would be trivial. It would require a table scan but the are only 7300 records.
But if you determined that a lot of queries like that were going to be run every hour (or second) then you should indeed create an analysis table which does the sum for the result.
At some point you are going to run into indexing problems with that approach. One solution is to simply duplicate the data. Again there just isn't enough data that duplicating it is a problem. Each "group" would have duplicated data. If you use the same primary key for the duplicated data it would be trivial (and fast) to do cross group queries as well (like a query for the sums of 20 that also occurred on tuesday.)
Note that it doesn't really matter if you need to create several hundred analysis tables. Again the size is so small that it isn't even meaningfull to discuss sizing the database even then. Your only real concern with that number of tables is ensuring that associations are kept low (no explicit cross group associations.)