load entire db to data model?

I've decided to use the e开发者_Go百科ntity framework as data layer.

I have more then 200 tables, and two questions:

1. When creating the data model (*.edmx) - should I include all tables (entire db)?

2. Later, will I be able add tables to the data model?

---

Typically you want to represent all tables in your data model, otherwise you cannot access them as entities. One strategy for larger database schemas such as yours is to split it into separate parts (separate .emdx files) that together constitute the data model - having a single .edmx model can slow down VS at some point - I personally have not experienced this though, so you will have to try it out yourself - creating the initial model from an existing database is done easily and without effort.

You will be able to add tables at any point to the data model, the integrated wizard allows you to pick and choose which tables you want to add just by pointing it to an existing database.

---

I agree with @BrokenGlass. VS 2010 SP1 should have improved performance of the designer which works much better with larger models but still 200 tables in single model is too many.

ADO.NET team published two articles about working with large models: Part 1 and Part 2. Generally these articles are not only about splitting your mapping into multiple EDMXs but also about sharing some common entities in multiple EDMXs which can be really helpful. Without this sharing you can't an reference entity from one EDMX in another EDMX. Also each EDMX will have its own ObjectContext. Spliting a mapping into multiple EDMX should be based on some architecture decission: for example split by a component or split by an aggregate root. Anyway using multiple EDMX will increase the complexity of the application and you must still understand that EF features don't work accross multiple EDMXs - so for example you can't create a linq-to-entities query on top of entities mapped in different EDMXs.

I answered a question where I describe some hack how to use multiple EDMX files in the single ObjectContext but I recommend not using that solution until you must - the only meaningful usage of that solution is separate EDMX for entities updated from database and separate EDMX for SSDL defined manually (for exemple custom DefiningQuery). The reason is that Update from database function will delete your changes so it is helpful to keep them separately in EDMX which is never updated.