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 回答