如果我理解你的话...



如果你想在所有者和手机之间创建多对多关系，你需要创建3个表：

1）Supliers_phones

2）Customers_phones

3）Vendors_phone



每个应包含2个外键：

1）Suplier /客户/供应商FK

2）电话FK



但是......

我建议通过创建4个表来规范化数据：

If i understand you well...

You need to create 3 tables, if you want to create many-to-many relationships between owners and phones:
1) Supliers_phones
2) Customers_phones
3) Vendors_phone

Each of it should contain 2 Foreign Keys:
1) Suplier/Customer/Vendor FK
2) Phone FK

But...
I'd suggest to normalize data by creating 4 tables:

OwnerType (OTypeID INT IDENTITY(1,1), ODescription NVARCHAR(155))
Owners (OwnerID INT IDENTITY(1,1), OName NVARCHAR(155), OSurName NVARCHAR(155), ONickName NVARCHAR(155), OBirthDay DATETIME, OTypeID INT (FK - reference to OwnerType table))
Phones (PhoneID INT IDENTITY(1,1), PNumber (?), PCompany (?), PAreaCode(?))
Owners_Phone (OwnerID INT (FK - reference to Owners table), PhoneID INT (FK - reference to Phones table))

注意：这是唯一的建议; ）

Note: it's only suggestion ;)

大家好。



特别感谢Maciej Los对这个主题的关注。



我到目前为止找到的解决方案与我在EF4.1中使用的解决方案类似，即：



- 创建一个简单的基本界面，只有Id，我称之为IOwner;

- 创建IEnterprise和IPerson接口，没有属性的注册标识，也就是说，没有密钥;

- 创建一个抽象类（Person）来实现IOwner和IPerson;

- 创建一个抽象类（Enterprise）来实现IOwner和IEnterprise;

- 创建继承自Person的具体类Student，User和Vendor;

- 创建具体类从Enterprise继承的客户，供应商和Office;

- 在实现IOwner和电话和电子邮件表的每个具体类之间创建具体的类连接。



虽然它相当复杂，但结构可以在学生表，用户，供应商，客户，供应商和办公室以及电话和电子邮件表中保持一对多的关系。



但是这个实现将迫使我为从IOwner派生的每个类保留一个专门的存储库，在那里我为电子邮件和手机的CRUD创建了必要的功能。



我认为EF6会有任何可以促进这种实施的消息。如果有人知道在我的问题中引用的其他更专业的创建实体的方式，则是一个尚不存在的强烈迹象。



我采用的解决方案效果很好良好的表现，但我确实得到了一个强烈的印象，成为一个看起来非常学习的解决方案。如果这个解决方案对我以外的任何人都有用，我感到非常高兴。



无论如何，感谢大家的耐心和专注。



加强，如果有人知道如何在我出发的情况下以更专业的方式应用EF6，请提前感谢您的分享。

Hello everyone.

Special thanks to attention given to the subject by Maciej Los.

The solution I found so far was similar will that I used in EF4.1, ie:

- Create a simple basic interface, only with the Id, which I called IOwner;
- Create the IEnterprise and IPerson interfaces without a registration identification of property, that is, without a key;
- Create an abstract class (Person) to implement the IOwner and IPerson;
- Create an abstract class (Enterprise) to implement the IOwner and IEnterprise;
- Create the concrete classes Student, User and Vendor inheriting from Person;
- Create the concrete classes Customer, Supplier and Office inheriting from Enterprise;
- Create concrete classes connection between each of the concrete classes that implement IOwner and Phone and Email tables.

Although it was fairly complex, the structure can maintain a kind of relationship One-to-Many among the Student tables, User, Vendor, Customer, Supplier and Office and the Phone and Email tables.

But this implementation will force me to keep a specialized repository for each class derived from IOwner where I created the necessary functionality to CRUD of emails and phones.

I thought the EF6 would have any news that could facilitate this implementation. If anyone knows other more professional ways of creation of entities quoted in my question, is a strong indication that does not already exist.

The solution I adopted works well and with good performance, but I did get a strong impression of being a solution that looks very "learner". And I'm very pleased if this solution is useful for anyone other than myself.

Anyway, thank you all for your patience and dedicated attention.

And strengthening, if anyone knows how to apply the EF6 in a way that appears to be more professional in case I set out, thank you in advance for sharing.