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

Question

Do you intend to use one Entity Data model for each table? Or one for your entire database, where relationships are also routed, etc.

Answer 1

Do this for the entire database. If you create a data model for each table, you will not be able to use relationships.

If you use a control / merge control, such as Subversion, keep in mind that the designer scares the XML to such an extent that Subversion tries to merge it. In this case, you usually have to regenerate the entire model each time or merge manually.

Answer 2

I am using an entity data model for linked tables. Depending on the size of your database, I would create only one model if there were less than 20 or 25 tables. It's a little expensive to create separate models for each table, since each model has an EntityConnection object to be created.

I find that I can support models well if I have 5 to 15 tables. The main deciding factor is functionality. I am building engineering applications, for example, I have about 6 tables of structural steel components. All of them are in one model. They have common engineering attributes, so it’s easier to reuse code specific to managing these attributes.

This means that I can create an instance of the model, create objects, manage these objects in a common code file. Any changes that need to be transferred back to the database can be made quite efficiently.

The bottom line defines your need and frequency of use for basic objects. If you are going to constantly update one or two tables, then it makes no sense to have 30 other unrelated tables inside this model. In this case, when a small number of tables are often used, it may make sense to create collections of these objects, manage collections, and update the database at the appropriate time.

Maipulation memory is much cheaper than performing I / O. This is just my view of the framework, and by no means am I an expert in this.

Answer 3

One for your entire database, or at least for the tables you will use ...

If you have a large number of tables, you can break them into schemas or some other categorical method, but I would say that the idea was never a data model for a table ...

Answer 4

I would develop a conceptual / object data model independently of the database schema, and then create a mapping that best connects the conceptual model with the database schema. It can use most, if not all, tables. If you need a one-to-one mapping against tables, you might want to use LINQ-to-SQL instead, since it is easier to work with.

Answer 5

In addition to the answers above, keep in mind that the EF model is actually at a conceptual level. It should not have anything to do with the structure of your database and, of course, should not represent the entire database.

Answer 6

I think that if you have a large database, you need to classify the database tables. But you need to create a class for each table, which is the basic requirement for the ado.net entity infrastructure.

When you update the database, you can do this using the update data model.

First create your database, then create an ado.net entity model.