Is it better to have one fat data context class with all the tables in it or break them into smaller classes and potentially having "single table" classes?
From organizational standpoint I feel like I shouldn't split relations over several data contexts (I don't even think it's doable). But on the other hand I think that creating a whole new instance of that fat class just to query a single, unrelated table is an overkill.
What do you think?
Depends on the number of tables you've got. If its say less than, say, 20, i personally wouldn't split it up.
If you wanted, you could split by task, or by relationships, or by purpose.
Up to you, i'd say, really. The thing i'd be keeping foremost in my mind is 'which is the most maintainable way to do this?' when deciding whether to split them up.
It's not expensive to construct a data context regardless of how many tables it manages, so that shouldn't be a criterion when deciding whether to have one or more separate data context implementations. A new data context is "empty" until you actually start using it, and table instances are created as needed.
What makes a data context instance expensive is when you use the same instance over and over again for tracking changes to different objects - for example, using a cached instance of a data context in an ASP.NET application for all database operations (now that's a no-no).
As long as you use the data context as intended, in a unit-of-work pattern, it doesn't matter how many tables it can manage at the class definition level, as you only instantiate the ones you need within the current unit of work.
To me, the data context logically represents the target database, so it should represent all the entities that are mapped within that database, whether there are 10 or 100 - splitting it up really offers no benefit other than less lines of code in a given class, but if that's something you care about then by all means, have different classes.