none
Multiple database support (with entity relations across databases in same sql server instance)

    Dotaz

  • I love all the amazing work that has been done with the ADO.NET Entity Framework and Data Services.  There is one piece that I can't find any information on, however:  Support for multi domain models or multiple databases in the Entity Framework (and thus Data Services).

    We have 10+ large enterprise databases all hosted on the same server/instance of sql server and these databases are somewhat used as "schema" conatiners, i.e. we have many stored procedures that make calls to stored procedures/tables/views in another database and there are logical relationships between tables in different databases.  This requires our Entity Model to have entity relationships across databases and thus across Entity Models (since, AFAIK, currently the Entity Framework design surface can only include tables from one database).

    I believe that this is a big weakness and needs to be addressed as soon as possible.  The other issue I have is how much the Entity Framework design surface slows down (and the entity boxes become unmanageble from a visual real-estate perspective) after about 20-30 tables on it...

    Any comments on this from the Entity Framework team would be very much appreciated...

     

    12. března 2008 19:22

Odpovědi

  • Relationships that cross database lines are simply out of scope for the entity framework.  Yes, it is a limitation, and it is something we might address at some point, but it's not a feature I would expect soon.

     

    Performance of the design surface in the face of many tables is something I'll let the designer team comment on.

     

    - Danny

    15. března 2008 6:03
  • Regarding the performance of the designer, we regularly work with the AdventureWorks model, and find the performance to be quite acceptable.

     

    We also have some test databases that have many hundreds of tables - the performance and usability at that point are borderline at best. We are looking at various features in v2 to make schemas of this scale easy to work with.

     

    One feature that we are adding that will make v1 is the ability to right-click an entity type in the model browser and select "Locate on Diagram", which should make working with medium sized schemas more reasonable.
    17. března 2008 16:44
    Moderátor

Všechny reakce

  • Relationships that cross database lines are simply out of scope for the entity framework.  Yes, it is a limitation, and it is something we might address at some point, but it's not a feature I would expect soon.

     

    Performance of the design surface in the face of many tables is something I'll let the designer team comment on.

     

    - Danny

    15. března 2008 6:03
  • Regarding the performance of the designer, we regularly work with the AdventureWorks model, and find the performance to be quite acceptable.

     

    We also have some test databases that have many hundreds of tables - the performance and usability at that point are borderline at best. We are looking at various features in v2 to make schemas of this scale easy to work with.

     

    One feature that we are adding that will make v1 is the ability to right-click an entity type in the model browser and select "Locate on Diagram", which should make working with medium sized schemas more reasonable.
    17. března 2008 16:44
    Moderátor
  • I know this is an old post, but i haven't seen much on this topic. Is this still the case with the released product? Our legacy systems have separate databases for Products and Orders, for example, and I can't figure out how or if I can use Entity Framework to model and map these entities and their relationship. Probably not the best DB design, but its not gonna change.
    11. září 2008 0:37
  • This has not changed. Now note that SQL server allows you to write queries and create views that span multiple databases. So, if you can create a set of views and update/delete/insert stored procedures against those views, then you may be able to get this to work...we should probably put out a sample on this...

    11. září 2008 2:17
    Moderátor
  • That would be very useful, esp. for newbies like me who are using the designer and "feeling our way" around. Thanks for the reply.

     

    11. září 2008 2:26
  • Most unfortunate that you have chosen to exclude this feature.  It is, aside from being provider-neutral, the most useful element of entity-relationship modeling.

    We have heterogenous data sources which for performance and maintenance reasons will not be consolidated and linked servers and synonyms have their own limitations.  I would love to see a solution where a single entity-relationship model can support multiple connections to multiple databases.  Then you will have a true data abstraction layer.

    Until then, looks like nHibernate is still our only option
    11. září 2008 15:11
  • I would have to agree that its a disappointing exclusion, and that the linked server route is not always practical. A pity that its not even on the roadmap

    24. října 2008 20:31
  • If this is still the case, I must also express my disappointment. I figured entity mapping would support such a thing. It's easy to query between two databases. I don't see why I should have to create a new ADO Entity item for each database.
    Thanks. :)
    17. března 2009 5:25
  • Its a year later is this still the case?

    If it is I would also like to express my disapointment that this has not changed.

    2. dubna 2010 17:02
  •  

    Hi Tolga.

    I wrote a post. Entity Framework with Linked Server.

    The difference is that the linked server uses four parts name (server.database.schema.table) and other database using three parts (database.schema.table)

    See:

    http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/4acbf58d-30a5-44ec-9b3b-784af9b9bbaa

    I hope it helped.

    Rafael Krisller


    "A próxima grande evolução da humanidade será a descoberta de que cooperar é melhor que competir"
    16. července 2010 18:22