Thanks Joe, Lynn & Grant! Your insights are all very helpful!

We do not have Enterprise Edition. A local partitioned views approach may be appropriate; we had not really considered this approach. Very interesting!

Up till now, we'd been thinking of tossing everything into one big table, such that each day we'd add new records containing last night's activity, and then run a DELETE query to nuke records that had been imported more than 30 days ago.

Given the size of the stuff to be imported, this is a lot of data churning, and thus the log could grow large quickly. That's why we were wondering about what size we should set it to in the initial creation of the database (and what autogrowth, if any, we should allow).  Once imported, there will be zero editing of the data; we'll just be running a bunch of SELECT queries on it. Perhaps my question should have been more along the lines of, "what log size would generally make sense in this sort of data-warehouse situation? "

Given that we'll be checking daily to make sure last night's import went okay, should the log be just large enough to serve as a record of what occurred during last night's import routine? Or maybe we should hold a few days worth of activity, to account for weekends when staff might not be able to verify that last night's import ran okay?

I apologize if my questions seem confused or uniformed.  Our staff is spread across a dozen different projects with (of course!) different technologies and platforms and none of us is a SQL Server expert.  Your insights really are valuable, thanks again!  

Thanks again!