实体框架不会解决与复合主键的PK-FK关系？

Question

我正在尝试在现有SQL Server基础架构上设置EDM，并遇到了问题。

EDM将不解析与复合外键的PK-FK关系。

我的数据库表结构看起来像这样（名称已更改以保护无辜者）：

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

到目前为止我？希望我还没有失去你。完成所有操作后，我的结构如下所示：

此结构在SQL Server中运行良好。在EDM？没那么多。它不允许我构建OFFICEPERSONSLOCATION和OFFICEPERSONS之间的关系。我收到以下错误：

  

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

咦？数据不一致？！？怎么样？

如何让我的实体框架识别出来？

Answer 1

我同意这是实体框架的问题，问题是愚蠢的。即使您将UPDATE CASCADE设置为“无操作”，也不会产生不一致，但不是，它声称您可以以某种方式。

在任何情况下，在这种情况下，如果您愿意使用代理键而不是复合键，您可以解决这个问题，因为这是唯一可以改变的地方ID引用位于主表中。

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