Adam, Phil:

We hear you, and we're working on it. There are difficulties associated with information that Microsoft exposes (or doesn't) about foreign keys on its EntityObjects, and as the EF software is still itself in beta this is a moving target. Initially Microsoft didn't expose the foreign keys on *any* entities and enough developers complained that they began doing so.  And there are a whole special set of issues with the linking entities that the EF hides altogether. But we'll get it working, so stay tuned.

For those designing new databases, I'd like to make the case for always using a single-column, arbitrary primary key (which, from the EF's viewpoint, constitutes payload) in every table.  This solves the EF issues and is, I think, desirable for other reasons as well.  Eliminating the primary key style as a discriminator between linking and other tables gives you a nice flexibility to let the entities embodied in linking tables evolve into things that have significance in the own right (as does an Order that serves as the linking entity between Customers and SalesReps, Customers and Shippers, and SalesReps and Shippers.) You treat all entities the same way, as far as primary key is concerned, and a type can evolve as needed without causing you to change your style of working with it mid-stream.  In the EF, the distinction between how entities with and without payload are handled guarantees that you *will* have to change your strategy if a payload-free linking entity suddenly needs to be made richer.  I'd rather just allow for such evolution up front.

It's easy to code many-to-many navigation properties into your entities. Each such property takes a couple of lines of code (one line if you wish!). We could generate them, too, if we were to see sufficient demand for that. The problem there is that not all many-to-many relations defined in a database are necessarily significant from a business viewpoint, and we don't want to generate a lot of unnecessary stuff; so then we might need a UI to allow you to tell us which of the many many-to-manys you actually want. 8-) But it could certainly be done.

Greg Dunn

Training and Documentation Manager

IdeaBlade

I have a database that has many tables that follow the same relationship structure: