Should I create a ADO.NET Entity Data Model for each table, or one for my entire database?

Question

Hi,

Are you supposed to use one ADO.NET Entity Data Model for each table? Or one for your entire database where relationships are also routed, etc...

Answer 1

One for your entire database or at least the tables you will be using...

If you have a large amount of tables you could break them up into schemas or some other categorical way, but I would say that the idea has never been data model per table...

Answer 2

Do it for the entire database. If you make a data model for every table you will not have the benefit of navigating the relationships.

If you're using checkout/merge source control like Subversion, be aware that the designer munges the XML to the extent that Subversion struggles to merge it. In this case you usually have to regenerate the entire model every time or merge by hand.

Answer 3

I think If you are having large database then you need to categorize the database tables. But you have to create a class for each table that's a primary requirement of the ado.net entity framework.

When you update database then you can do with update data model.

First design your database then create ado.net entity model.

Answer 4

I would design a conceptual/object model of the data independently of the database schema and then create the mapping that best relates the conceptual model to the database schema. It may use most if not all of the tables. If you want a one-to-one mapping to tables, you may want to consider LINQ-to-SQL instead, since it's easier to work with.

Answer 5

I use an Entity Data Model for related tables. Depending on the size of your database I would only create one model if there was less than about 20 or 25 tables. It is a bit expensive to create individual models for every table because each model has a EntityConnection object to be created.

I find I can maintain the models fairly well if I have between 5 and 15 tables. My main deciding factor is functionality. I build engineering applications so for example I have about 6 tables of structural steel components. They are all in one model. They share common engineering attributes so it's easier to reuse code that is specific to manipulating those attributes.

This means that I can instantiate the model, create the objects, manipulate/organize those objects within a common code file. Any changes that need to be propogated back to the database can be done quite efficiently.

The bottom line is determinig your need and frequency of use for the underlying objects. If your going to be constantly updating one or two tables then it doesn't make sense to have 30 other non-related tables inside that model. In this scenario where a small number of tables are being used frequently, it might make sense to create collections of these objects, manipulate the collections and update the database at appropriate times.

Memory maipulation is much cheaper to perform then disk I/O. This is just my take on the framework and by no means am I an expert at it.

Answer 6

In addition to the answers above, keep in mind that an EF model is actually at a conceptual level. It doesn't need to have anything to do with the structure of your database, and certainly doesn't need to represent the entire database.