look - your database idea makes sense - and you may be able to get by without a vast number of changes
but take your basic premise that you need 4 weeks data with 60 columns each.
what happens in the 5th week? do you drop the first week? then you end up with multiple databases, one for each 4 week period. That isn't the way it should work,
so, instead of a table with 240 columns data, you could have a table with all the weekly data in it, with 60 columns, with the edition of a field for say weekending date
instead of a table with this structure (unnormalised)
week1data ... week2data ... week3data... week4data
you have a table with this normalised (or better normalised structure)
date weeklydata
some developers might want to split this latter table further - it all depends on what the data is, and how you need to manage it.
now - with this latter structure, if you want to get a total for the last 3 months, or indeed any date range - it's far easier - however if you want to compare a week with a previous week it becomes a bit harder, as you need to manipulate the data to get into a form that enables a comparison to take place.
Nevertheless this latter structure is the right way to go, as the benefits far outweigh any drawbacks.
hence the observation that a database should not be regarded as a spreadsheet, and should not be constructed as you might construct a spreadsheet.
