<div>
No you don't have the wrong idea. But possibly the wrong reason...<br />
<br />
While you are not locked into a single datbase model, you end up with tons of complex types redefining basic &quot;blocks&quot;, and they are often inherited, so the complexity of the CSDL schema becomes heavily involved, to the point where sometimes it is easier to build a CSDL schema for a specific database model. So, the schema becomes locked into a single database model only, not the approach, not the system. <br />
<br />
There in lies the difficulty of using such a model to be able to use some of the &quot;rich&quot; value-add features of your own system, it ends up being the lowest denominator of the database you want to work with, and then you must understand the inherent business and transaction logic of that database (different but related problem to your question though).<br />
<br />
Take the humble address... &nbsp;Invariably, it must take on a complex type such as :<br />
<br />
&nbsp; &lt;ComplexType Name=&quot;Addresses&quot;&gt;<br />
&nbsp; &nbsp; &nbsp;&lt;Property Name=&quot;Street&quot; Type=&quot;string&quot; nullable=&quot;false&quot;/&gt;<br />
&nbsp; &nbsp; &nbsp;&lt;Property Name=&quot;City&quot; Type=&quot;string&quot; nullable=&quot;false&quot;/&gt;<br />
&nbsp; &nbsp; &nbsp;&lt;Property Name=&quot;State&quot; Type=&quot;string&quot; nullable=&quot;false&quot;/&gt;<br />
&nbsp; &lt;/ComplexType&gt;<br />
<br />
&nbsp; &lt;EntityType Name=&quot;Contact&quot; Key=&quot;ContactId&quot;&gt;<br />
&nbsp; &nbsp; &nbsp; &nbsp; &lt;Property Name=&quot;ContactId&quot; Type=&quot;Int32&quot;/&gt;<br />
&nbsp; &nbsp; &nbsp; &nbsp;&lt;Property Name=&quot;Address&quot; type=&quot;Addresses&quot;/&gt;<br />
&nbsp;&lt;/EntityType&gt;<br />
<br />
<br />
So, what do you then do with a database that has Address1, Address2, Address3, State, Country, Postcode ? How do you then map them back into your own application. So, then your address construct really becomes and AddresType entity and you set up your new address with basestype = &quot;AddressType&quot; and add in the extras. You need to then start accommodating a wider ranging address construct, even if not immediately of benefit. And then you cannot hang any logic off those types that cannot be directly mapped, or is referencable within your app. As a poor example, it is like trying doing regional analysis based on ZIP or Postcode but first having to traverse address3, suburb, state, country before you can identify where you really are. &nbsp;Big overheads trying to accommodate all that flexibility, and in reality, does not support the spatial types anyway (just yet).<br />
<br />
So, while it does promise a lot, when it comes down to practical applications then it does become more difficult, more involved. Not impossible, but part of the allure is to make it quicker and simpler and in reality it becomes more involved and more complex, especially when you start to consider relationships and inherited types - how do you place a foreign key or a primary key on an inherited type - and doesn't that now undermine some of the relationaships that surely must exist at the &quot;natural&quot; level ? &nbsp;So, there are a few challenges to get your mind around.... <br />
<br />
Have used the model on a reporting portal - mind you it did not have to sit across a variety of databases in the end, it was an internally / seperately controlled database with a few areas of user defineable space in the way they wanted to construct their security mappings. Any immediate benefit over a more traditonal model were not immediately obvious other than in development stages, but that was more the application of it. <br />
<br />
Anyway, there is some interesting reading out there - sounds as if you have already done some :<br />
<br />
From the MSDN site : <a href="http://msdn.microsoft.com/en-us/library/aa697428(VS.80).aspx" rel="ugc nofollow">http://msdn.microsoft.com/en-us/library/aa697428(VS.80).aspx</a><br />
<br />
And found the team blog to be pretty good - included the comments posted down the bottom... &nbsp;<a href="http://blogs.msdn.com/adonet/archive/2007/01/30/entity-data-model-part-1.aspx" rel="ugc">http://blogs.msdn.com/adonet/archive/2007/01/30/entity-data-model-part-1.aspx</a>
</div>


<div>
Well! Many thanks for the excellent post. You raise very interesting points. I have some more reading to do before I answer further. It looks like the bottom line is that the Entity Model is tied rather tightly to a single database schema...<br />
John
</div>


<div>
Mark,<br />
Sorry for the delay in closing this.<br />
In doing more reading, you r comments make a great deal of sense. It also appears that this concept in sort of in its infancy. It will be interesting to see how it shakes out in the long term.<br />
Thanks agin for the valuable insight.
</div>


<div>
Happy to help :) &nbsp;And yes, it is going to be very, very interesting to see it unfold :) &nbsp;I am not yet sure if there is any absolute best solution for applications that must be data driven and data aware as to how far removed from the real data they really can be - if it is simply &quot;information&quot; then fine, but if there is some process or procedure then it becomes considerably more challenging unless you then start parameterising the rules and data interactions themselves and I am afraid that is where we get to see some significant performance issues with volumes of users and of data, whilst all the time the &quot;green&quot; developer has come up with yet another coding milestone without little thought of the real reasons we are here - to provide tools to the end user community to enable them to get their job done more efficently and more effectively (I will jump off the soap box now). <br />
<br />
Cheers,<br />
Mark Wills,<br />
<br />
p.s. drop back in and let us know what you get up to...
</div>


<div>
<div class="content wysiwyg-content">
The .NET Entity Data Model seems like a cool idea. You code against the abstract model without caring what the underlying data really looks like in the DB. <br />
<br />
But if you design a general Entity Model for your app, can you then associate that with several different mappings to fit different databases that your app might ultimately work with?<br />
<br />
As a trivial example, let's say I want to build a neat name and address card file app. I design an Entity Model for names and addresses. But I want this to be built in one case against an ERP's database. For a different build I want it to run against some e-mail system's Address Book database. In a third build it runs against a client's custom in house database.<br />
<br />
It looks to me like an Entity Model is locked to a single database model. If this is the case, it looses some of its allure.<br />
<br />
Do I have the wrong idea here?<br />

</div>
</div>


The .NET Entity Data Model seems like a cool idea. You code against the abstract model without caring what the underlying data really looks like in the DB. 

But if you design a general Entity Model for your app, can you then associate that with several different mappings to fit different databases that your app might ultimately work with?

As a trivial example, let's say I want to build a neat name and address card file app. I design an Entity Model for names and addresses. But I want this to be built in one case against an ERP's database. For a different build I want it to run against some e-mail system's Address Book database. In a third build it runs against a client's custom in house database.

It looks to me like an Entity Model is locked to a single database model. If this is the case, it looses some of its allure.

Do I have the wrong idea here?


.net Entity Data Model: possible to have multiple mappings for one Entity Model

The .NET Framework is not specific to any one programming language; rather, it includes a library of functions that allows developers to rapidly build applications. Several supported languages include C#, VB.NET, C++ or ASP.NET.

.NET Programming

Databases are organized collections of data, most commonly accessed through management systems including schemas, tables, queries and processes that allow users to enter and manipulate the information or utilize it in other fashions, such as with web applications or for reporting purposes.