I have a project that interacts with a database through ADO.net Data Services. The database is large (almost 150 tables with dependencies). The project started a few years ago and there were DataSets used then; now we’re moving towards entity model relationships. The model is growing since we are adding more tables we need to work with. Is this a right way to manage all that?. Meaning should I have a SINGLE database model file to have single data context?
What are drawbacks and how do you use the entity framework with large databases (or should it not be used with large ones?
The disadvantages I see are:
- Visual Studio 2010 starts to freeze
when opening that large XML in the designer (maybe this is NOT a problem, because even with many tables it doesn’t freeze for long time). - It becomes hard to find references in
the model (though F4 + properties window’s combobox of object names almost
removes this search related problem).
PS, strange that no one answers. The question seems important and in simple words I’ll just rephrase it: Which is better, one model of whole a whole, large database or several models of that database?
I suspect you aren’t getting many answers because it’s not a big problem. Even in both your disadvantages you say they’re not really problems. Certainly EDM is fine working with big databases. I’d argue the larger the database the more the need for an ORM solution.
However you can have one model split over multiple files if that would help you keep things organised – i.e. multiple .edmx files can constitute a single data context.
Alternatively if you can logically split the model into isolated parts that can interact via interfaces rather then needing to directly join entities in the data context that is good for both managing the entity data model, and also just for basic separation of concerns.