I am trying out Linq to SQL in an ASP.NET application that uses a large database with lots of foreign keys (100+ tables). I am impressed with how Linq permits you to create
I believe that data context are pretty lightweight, mostly just containers. The data isn't actually loaded into the context until you query it. I don't think it would be wrong to have a single data context, but only instantiate it as needed (as a unit of work) rather than keeping it around all the time. That way, you don't have a long-lived object that may continue to grow bigger and bigger.
If your tables can be separated into related groups of tables, you may want to consider having a separate data context for each of these groups. I'm not sure how LINQ would handle a query using data from multiple contexts, but it seems like it ought to work as long as the tables are on the same server. You'd have to check this if you did break things down into multiple contexts and had queries that needed tables from more than one.
Typically I use a single context and instantiate it as needed, but I don't have any databases that are quite as big as yours.