By now you know I’m prone to exaggeration so that “billions” thing is a stretch, but you get the point hopefully.
Lots of legacy databases have hundreds or even more tables in them.
People building Entity Data Models by reverse engineering a database often bring every table and view from the database into a single model.
Here’s an untouched model built from all of the tables and view of the AdventureWorks database – totalling about 95 entities.
This is already unmanageable and causes design time performance issues, and it’s not even 100 entities.
I get questions all of the time from developers asking what to do with large models.
Here is a recent question I got via email":
“I have a database with 150+ tables. Would you break the model up into multiple edmx files?”
My response (with some enhancements for the sake of this blog post):
Yes I would. I have lots of clients working with multiple models. One approach is to think of a model per transaction. E.g., if you have a data entry screen that only needs 6 entities, build a model for that. (That may be exaggerated).
Take a look at:
http://www.ideablade.com/WardsCorner/WardsCorner_home.aspx scroll down to his large model discussion & demo. Ward and I have come up with the same conclusion. Ward has written something like a dissertation as he goes through the pros & cons of various approaches to the problem.
Also, another approach to consider (with or without breaking up the model) is a different designer that doesn’t try to visualize all of the entities (which makes things so cumbersome with the EDMX designer). LLBLGen Pro is already a great ORM in its own right. But they’ve taken their knowledge and built a deisgner specifically for EF4 with the goal of dealing with larger models.
Finally, just as an FYI, I’m guest editing an upcoming issue of DevPro Connections magazine and specifically asked Patrik Lowendahl to write an article on this very topic.