3

我正在尝试在现有 SQL Server 基础结构上设置 EDM,但遇到了问题。

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

我的数据库表结构看起来像这样(更改名称以保护无辜者):

  • 我有一个 PERSONS 表,其中包含一个名为 PerID (PK) 的 INT 列
  • 我有一个 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 中效果很好。在电火花?没那么多。它不允许我构建 OFFICEPERSONSLOCATION 和 OFFICEPERSONS 之间的关系。我收到以下错误:

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

嗯?数据不一致?!?如何?

如何让我的实体框架识别这一点?

4

1 回答 1

2

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

无论如何,在这种情况下,如果您愿意使用代理键而不是复合键,则可以解决这个问题,因为更改 ID 引用的唯一位置是在主表中。

在这种情况下,OffID 可能是“不一致的”,但是通过在 OFFICEPERSONS 和 OFFICELOCATIONS 表中使用 ID(因此在 OFFICEPERSONSLOCATION 中引用),您必须在其主表中管理 OffId。

于 2014-02-13T21:23:30.943 回答