miércoles, 12 de marzo de 2008 19:22
Todas las respuestas
sábado, 15 de marzo de 2008 6:03
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.
lunes, 17 de marzo de 2008 16:44ModeradorRegarding 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.
jueves, 11 de septiembre de 2008 0:37I 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.
jueves, 11 de septiembre de 2008 2:17Moderador
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...
jueves, 11 de septiembre de 2008 2:26That would be very useful, esp. for newbies like me who are using the designer and "feeling our way" around. Thanks for the reply.
jueves, 11 de septiembre de 2008 15:11Most 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
viernes, 24 de octubre de 2008 20:31
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
martes, 17 de marzo de 2009 5:25If 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.
viernes, 02 de abril de 2010 17:02
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.
viernes, 16 de julio de 2010 18:22
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)
I hope it helped.
"A próxima grande evolução da humanidade será a descoberta de que cooperar é melhor que competir"