Sql server 实体框架赢得'；是否使用复合主键解决PK-FK关系？

我试图在现有SQL Server基础架构上设置EDM，但遇到了一个问题

EDM不会将PK-FK关系解析为复合外键

我的DB表结构如下所示（更改名称以保护无辜者）：

• 我有一个PERSONS表，其中包含一个名为PerID（PK）的INT列
• 我有一个OFFICE表，其中包含一个名为OffID（PK）的INT列
• 我使用一个名为OFFICEPERSONS的表将这些表绑定在一起，在人员和办公室之间创建多对多关系。此表有两个INT列PerID和OffID，它们共同构成一个复合主键
• 我有一个名为OFFICELOCATION的表，它包含两个INT列，LocID和OffID。这两列组成一个复合主键。此外，OffID也是OFFICE表的FK
• 最后，我有一个名为OfficePersonLocation的表。此表有三个INT列：PerID、OffID和LocID。所有三列都包含一个复合主键。LocID和OffID为OFFICELOCATION提供FK关系，而OffID和PerID为OFFICEPERSONS提供FK关系

到目前为止和我在一起？希望我还没有失去你。说到底，我的结构是这样的：

这种结构在SQL Server中非常有效。在EDM中？没有那么多。它不允许我构建OfficePersonLocation和OfficePerson之间的关系。我得到以下错误：

错误6037:存储模型中省略了外键约束“FK_OfficepersonLocation_OFFICEPERSONS”。表“Model.Store.OfficePersonLocation”的列“OffID”是参与多个关系的外键。一对一实体模型将无法验证，因为数据可能不一致

嗯？数据不一致？！？怎么做

---

如何让我的实体框架认识到这一点？

我同意这是实体框架的问题，这个问题很愚蠢。即使您将更新级联为“no action”，也不是说您可以创建不一致性，但它声称您可以以某种方式创建不一致性

在任何情况下，在这种情况下，如果您愿意使用代理键而不是复合键，您都可以绕过它，因为更改ID引用的唯一位置是在主表中

---

在这种情况下，OffID可能“不一致”，但通过在OFFICEPERSONS和OFFICELOCATIONS表中使用ID（因此在OfficePersonLocation中引用），您将被迫在其主表中管理OffID。

我意识到实体框架通常不表示交叉引用表，而是使用多对多关系链接两个表，而不使用交叉引用表。这与我试图将一个交叉引用表与另一个交叉引用表链接有关吗？我被告知我的EF版本可能与此有关。不确定我运行的是什么版本，但我认为它早于EF4。我正在运行VS2010。谢谢你的回答；不幸的是，在我发布这个问题几天后，我当时所在的公司解雇了我。所以，除非我再次遇到这种情况，否则我想我永远都不知道这是否是答案。很抱歉听到这个消息。但是，在最近的实体框架中可以避免这个问题，但是如果您仔细考虑一下，在其中一个中间表中更改office ID将导致不一致。OfficePersonLocation Office ID是更改为Office Persons还是更改为Office Location？DB不知道。使用代理键时，OffID仅存储在主表中，因此ID始终保持一致。确实，尽管在该环境中，Office ID永远不会更改。