I run across this scenario all the time and I'll admit up front that I'm a developer not a DBA. However, I really don't think this is just a developer issue.
In my scenario, I have some sort of parent object ... in this example, a person. So, my first table is Person with a unique Id for each person. A person can have multiple addresses and persons can share addresses. So, we have an address table to store addresses with a unique Id. And, we have to have a Person_Addresses table which contains PersonId and AddressId fields to map the many to many relationship.
So far, no problems. The problem comes in when the relationship itself needs additional properties. For example, each address as related to a specific person needs to identify what type of address it is for that person. IOW, maybe Address with id of 1 is the primary address for Person 1 but it is the secondary address for Person 2. Or Address 3 is the Business address for Person 5 but is the Alternate address for Person 6. The most logical place to store this is with the join table. (I've run into this with phone numbers, a person's relationship to a loan (are they the grantor or grantee), etc.)
However, EF Code First does not provide a means to map this extra property. In order to work around this, I now have to create a new table Person_Address_Types ? and change the existing Person_Addresses to have properties PersonId and PersonAddressTypeId. Person_Address_Types contains PersonAddressTypeId, AddressId, AddressTypeId, etc.
The DBAs I've worked with don't like it when I tell them we have to create this unnecessary join table just so I can use EF. Are there any plans to allow mapping properties from a join table into an Entity object ... if not, can we turn this into a request or is this something that is just impossible to do?
What I would want to wind up with in the end is a Person entity that has an ICollection of Address entities and the Address entity would contain both the properties of the Address from the Address table as well as the properties such as AddressTypeId and AddressType (an entity related from the Address Type table).
Thanks for your help on this.
In my scenario, I have some sort of parent object ... in this example, a person. So, my first table is Person with a unique Id for each person. A person can have multiple addresses and persons can share addresses. So, we have an address table to store addresses with a unique Id. And, we have to have a Person_Addresses table which contains PersonId and AddressId fields to map the many to many relationship.
So far, no problems. The problem comes in when the relationship itself needs additional properties. For example, each address as related to a specific person needs to identify what type of address it is for that person. IOW, maybe Address with id of 1 is the primary address for Person 1 but it is the secondary address for Person 2. Or Address 3 is the Business address for Person 5 but is the Alternate address for Person 6. The most logical place to store this is with the join table. (I've run into this with phone numbers, a person's relationship to a loan (are they the grantor or grantee), etc.)
However, EF Code First does not provide a means to map this extra property. In order to work around this, I now have to create a new table Person_Address_Types ? and change the existing Person_Addresses to have properties PersonId and PersonAddressTypeId. Person_Address_Types contains PersonAddressTypeId, AddressId, AddressTypeId, etc.
The DBAs I've worked with don't like it when I tell them we have to create this unnecessary join table just so I can use EF. Are there any plans to allow mapping properties from a join table into an Entity object ... if not, can we turn this into a request or is this something that is just impossible to do?
What I would want to wind up with in the end is a Person entity that has an ICollection of Address entities and the Address entity would contain both the properties of the Address from the Address table as well as the properties such as AddressTypeId and AddressType (an entity related from the Address Type table).
Thanks for your help on this.
