C# 实体框架1通过关联表建立的1对1关系在EDMX中不起作用

我在SQL Server数据库中有以下表格

它有一个1-1关联表（FooBar），在对应的FooId，BarId上有唯一的索引，主键是（FooId，BarId）

需要明确的是，FooBar不允许任何FooId（由于唯一约束）在表中出现多次，也不允许任何BarId（由于唯一约束）在表中出现多次。这就是它成为1-1关联表的原因

我想要这个关联表，而不是Foo和Bar之间的1-1关系，因为在我的现实世界场景中，Bar与不同的不相关表之间有其他关系，我想要类似的关联表（而不是为每个新表向Bar添加新的FK列）

然后我将这些表放入我的EDMX设计器中。这种关系是多对多而不是一对一的。

这当然不是我想要的。我可以手动将模型更改为1-1关系。

但是我（在设计器中）得到了一个错误。

---

这是一个错误还是不可能在EF中以这种方式创建1-1关联？

就EF而言，您在第一张图中显示的关系不是1对1关系

Foo

和

Bar

这样想：

与以下

Foo

和

Bar

值的可能组合

Foo
1
2
3

Bar
1
2
3

FooBar
1, 1
1, 2
1, 3
2, 1
2, 2
2, 3
3, 1
3, 2
3, 3

您的FooBar表是一个复合键，这意味着它是构成键的Foo和Bar值的组合，而不是1对1的关系

要定义Foo和Bar之间的1:1关系，您的模式应该更像这样：

Foo
FooId PK

Bar
FooId PK FK to Foo.FooId

foo和bar之间的1对1关系不需要FooBar表

正如您在问题/评论中所述-是的，您在复合键的各个部分上设置了唯一约束，但EF在确定关系时不考虑模型的唯一约束。如果您想要一对一关系，您应该创建一个一对一模型，而不是通过唯一的约束模拟一对一关系。

这是整个EF设计的一个“缺陷”：实体框架4-6.1x只尊重主键上的多重性

因此，即使我们知道（和RA模型）由于候选密钥约束，它是1-1关系，EF也不会也不会喜欢它。真倒霉

“解决方案”包括：

将模型更改为EF理解的内容（EF首先理解代码，而不是RA）。当然，这可能表明所选RA模型存在“问题”，但这与问题是正交的

使用错误生成的多重性规则和“小心使用”；脏工作可以包装，但必须在自动生成的模型之外手动添加

。。嗯，其他的

无耻的未解决问题插件解决了同样的核心问题，但缺少以下功能：

---

它似乎来自SQL Server数据库关系图。FooBar表对FooId和BarId有唯一的约束，同时对这两个表有一个PK unique键。它是一个1-1关联。FooBar是一个多对多关联表。EF不是您的问题。@Augustobarertom请仔细阅读我的SQL设置，我在FooBar中对FooId和BarId有独特的限制。这是一个1-1关联表。@Jim好的，现在我明白了。对不起，我帮不了你。也许您可以尝试创建一个FooBar类，并在edmx中手动将FooBar表映射到它，但我不确定。很抱歉误解Jim，这里有另一个似乎相关的SO问题，可能会有所帮助？这是不正确的，因为在我的SQL表中，我对FooId和BarId以及PK（FooId，BarId）有唯一的约束。任何Foo-Bar组合只能有一个条目。i、 e.食物1在表中的出现次数不得超过一次，BarId 1相同。所以你的FooBar表示不是我设置的。唯一的约束是在哪个表上<代码>Foo和

条

？或者

FooBar

？我不确定EntityFramework是否会考虑到您的独特约束。为什么不能在实际的1to1关系中建模表，而不是通过唯一约束模拟1to1？我在问题中解释了这一点。我不想在添加新关系时向栏中添加列。我希望它与其他关系无关，因此使用关联表。我没有否决它。我讨厌投否决票。不要认为这是建设性的；-）有没有办法覆盖DbContext.OnModelCreating，通过代码强制关系绕过这个问题？@Jim我情不自禁：在对某个问题产生了许多不愉快的想法之后，我选择了选项#2。。但是我不认为Model/Schema是这样的，因为错误来自设计时生成器本身。（除非谈论完全从*DL中删除它，也许…）我曾经考虑过这样做，删除设计器中的关系并通过代码添加。以前从未尝试过类似的方法，混合模型。但我以前就知道我会像这样破解周围的bug：-）可能会给它一次机会。