通過關聯表的實體框架1to1關系在EDMX中不起作用

Question

我在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關聯？

Answer 1

這是整個EF設計的“缺陷”： 實體框架4-6.1x 僅尊重主鍵上的多重性 。

因此，即使我們知道 （和RA模型）由於候選鍵約束而是1-1關系，EF也不會也不會喜歡它。 倒霉。

“解決方案”包括：

1. 將模型更改為EF理解的內容（EF理解Code First，而不是RA）。 當然，這可能表明所選RA模型存在“問題”，但這與問題正交。

2. 生活在錯誤生成的多重性規則和“謹慎使用”; 臟工作可以包裝，但必須在自動生成的模型之外手動添加。

3. 嗯，其他人？

對未解決的問題的無恥插件處理相同的核心缺乏功能：

• 如何讓EF6在關聯/關系多樣性中遵守唯一約束（在FK上）？

• 如何將EF6關聯添加到不是主鍵的候選鍵/唯一鍵？

Answer 2

就EF而言，您在第一張圖形中顯示的關系不是1to1關系。

這是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之間的1to1關系不需要FooBar表。

正如您在問題/評論中所述 - 是的，您對復合鍵的各個部分設置了唯一約束，但EF在確定關系時未考慮模型的唯一約束。 如果您想要1to1關系，則應創建1to1模型，而不是通過唯一約束模擬1to1關系。