First, please confirm:

A previous poster suggested segregating the data by time period. Given that you note that the data will reach a maximum of 5,000,000 records, and your weekly addition of 100,000, I assume that this will ultimately either restart every (fiscal?) year, or end up being a running tally of the last 12 months' worth of data.

Therefore, further segregation by time period may not be practical/possible.

Second:

When are the reports run? Throughout the week, or right after the update hits? Are the reports run multiple times? with different selection criteria?

Assuming that the reports are run multiple times with different selection criteria, pre-built, report-specific tables (your second alternative) could well be an excellent solution.

It might not hurt to revisit the details of the reports as well; make sure that all the data going into the pre-built table is needed (now, or in the foreseeable future), and that there is no desire for additional data.

Delivery mechanism can come into play here, as well; if the reports are pasted into Excel spreadsheets, for example, you might see if setting up a pivot table (possibly with an underlying, offline data cube) would meet your users' needs. This moves the work off the server, so that you don't have any contention issues causing further slowdowns (plus does the sort of data re/preformatting you're talking about).

Finally, speaking of contention issues: Especially if some of the queries are convoluted, you might want to be sure you are employing the WITH (NOLOCK) hint. I have seen occasions where complex SELECT queries have locked data so no one else could run a query (even another SELECT!). Never did figure out the details, but it happened more than once.

Hope this is some help to you.