entity-framework - 如何让 EF6 遵守关联/关系多样性中的唯一约束(在 FK 上)？

Question

2019 年更新/TLDR；切换到 Entity Framework Core(或其他任何东西)

虽然缺少一些“功能”，但 EF Core 除了主键之外还正确地尊重备用键(又名唯一约束)，因此在尊重关系代数方面做得更好。 YMMV 否则；至少它正确支持更多的 SQL 方案。

添加的此支持位于(非常过时)EF Core 1.0 release .. 有点令人失望的是，最初的 EF 从未解决过这个设计(ed!)缺陷。

这可能和我的other question有关- 这似乎是:

Entity Framework 是一个糟糕的关系代数映射器1 或；

(我希望如此)我通常忽略了 SSDL/CSDL 和 EDMX 模型或 EF 映射。

我有一个 Schema First 模型，该模式如下所示:

ExternalMaps
---
emap_id - PK

Melds
---
meld_id - PK
emap_id - >>UNIQUE INDEX<< over not-null column, FK to ExternalMaps.emap_id

为了验证，这些脚本如下所示，这应该导致 ExternalMaps:1 <-> 0..1:Melds 的多重性。 2.

ALTER TABLE [dbo].[Melds] WITH CHECK ADD CONSTRAINT [FK_Melds_ExternalMaps]
FOREIGN KEY([emap_id]) REFERENCES [dbo].[ExternalMaps] ([emap_id])

CREATE UNIQUE NONCLUSTERED INDEX [IX_Melds] ON [dbo].[Melds] ([emap_id] ASC)

但是，当我使用 EDMX 设计器从数据库(SQL Server 2012)更新时，从头开始，它错误地将关联/外键关系创建为 ExternalMap:1 <-> M:Meld .

当我尝试手动将 Meld 的多重性(通过设计器中的“关联集”属性)更改为 1 时或 0..1 ，我得到:

Running transformation: Multiplicity is not valid in Role 'Meld' in relationship 'FK_Melds_ExternalMaps'. Because the Dependent Role properties are not the key properties, the upper bound of the multiplicity of the Dependent Role must be *.

(与我的其他问题一样，这似乎与未正确注册/作为候选键的唯一约束有关。)

我怎样才能让 EF 兑现 1 <-> 0..1/1模型建立的多样​​性？

1 虽然我希望情况并非如此，但当我试图让 EF 映射到一个完全有效的 RA 模型时，我的悲伤永无止境:LINQ to SQL (L2S) 没有这个问题。由于我的另一个问题对于如此流行的 ORM 没有简单的回答，我对这个工具失去了信心。

2 FK 不是另一种方式是设计使然:“虽然不应具有可为空的外键。” - 它也不是“共享”PK，因为这个answer from 2009建议作为修复。

我正在使用 EF 6.1.1、VS 2013 Ultimate，并且不会使用任何“OO 子类型功能”——如果这有什么改变的话。

编辑叹息:

Multiplicity is not valid because the Dependent Role properties are not the key properties? (从 2011 年开始)- 2014 年和 2015 年 EF“Microsoft 认可的企业就绪”ORM 是否仍然如此？

以这种速度，下次有人问为什么不使用 EF 时，除了“LINQ to SQL 工作正常”之外，我还会有很多其他原因..

Answer 1

问题是 Entity Framework (从 EF4 到 EF6.1，谁知道多长时间)不“理解”唯一约束的概念以及它们所暗示的所有内容:EF 映射代码优先，而不是关系代数 * 叹气*

This answer对于我的相关问题，提供指向 a request to add the missing functionality 的链接并总结:

.. The Entity Framework currently only supports basing referential constraints on primary keys and does not have a notion of a unique constraint.

这可以扩展到几乎所有处理唯一约束和候选键的领域，包括这个问题中提出的多重性问题。

如果 EF 的这种严重限制被公开讨论并“广为人知”，我会很高兴，尤其是当 EF 被吹捧为支持 Schema First 和/或取代 L2S 时。在我看来，EF 的中心是映射(和支持)Code First 作为一等公民。也许再过4年..