15

2019 年更新/TLDR；切换到 Entity Framework Core（或其他）

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

添加的这种支持是在（非常过时的）EF Core 1.0 版本中......有点令人失望的是，原来的 EF 从未解决过这个设计（编辑！）缺陷。

这可能与我的另一个问题有关- 这似乎是：

  1. 实体框架是一个糟糕的关系代数映射器1或；

  2. （我希望）我忽略了 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:Melds2。

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 的多重性（通过设计器中的“关联集”属性）手动更改为1or0..1时，我得到：

运行转换：多重性在关系“FK_Melds_ExternalMaps”中的角色“融合”中无效。因为从属角色属性不是关键属性，所以从属角色的多重性的上限必须是*。

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

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

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

2 FK 的设计并非相反：“尽管不应具有可为空的外键。” - 它也不是一个“共享”的 PK，因为2009 年的这个答案表明它是一个修复。

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

编辑叹息：

多重性无效，因为从属角色属性不是关键属性？（从 2011 年开始）- EF“微软认可的企业就绪”ORM仍然是这种情况吗？20142015 年？

按照这个速度，下次有人问为什么不使用 EF 时，除了“LINQ to SQL 工作得很好”之外，我会有一大堆原因......

4

1 回答 1

19

问题是实体框架（从 EF4 到 EF6.1，谁知道还要多久）不“理解”唯一约束的概念及其暗示的所有内容：EF 映射代码优先，而不是关系代数*sigh*

我的相关问题的这个答案提供了一个链接，指向添加缺失功能的请求并进行总结：

.. 实体框架目前仅支持基于主键的引用约束，并且没有唯一约束的概念。

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

如果 EF 的这种严重限制被公开讨论并“众所周知”，我会很高兴，尤其是当 EF 被吹捧为支持 Schema First 和/或替换 L2S 时。从我的角度来看，EF 的中心是仅将 Code First 映射（和支持）作为一等公民。也许再过4年..

于 2014-12-31T18:46:26.797 回答