如何在实体框架中创建嵌套的 one:many 关系？答案

【问题标题】：How to create nested one:many relationships in Entity Framework?如何在实体框架中创建嵌套的 one:many 关系？
【发布时间】：2014-09-01 02:53:53
【问题描述】：

所以我有一个由我们的 DBA 设置的架构，现在我需要将其转换为 SQL Azure。我在尝试将其转换为我们的 Azure 移动服务的 .NET 后端时遇到了一些麻烦。这是架构：

所有这些都是一对多的关系。因此，您会注意到存在关联多个表的外键。例如，在 Scenario 表中，projects 表和 area 表有一个外键。这是设置数据库的好方法吗？难道你不能把这些表关联起来以指向它们的父表吗？例如，在 Scenarios 表中，仅对 SubAreas 的 FK？起初我尝试在我的 Azure 服务中创建 EntityData 类，如下所示：

public class SubArea : EntityData 
{
    public string SubAreaAttenuation {get; set;}
    ...
    ...
    public virtual Area Area {get; set;}

    public virtual ICollection<Scenario> Scenarios {get; set;}
}

我需要在 SubArea 中为 Area 和 Project 提供明确的键吗？还是指向区域的指针就足够了？我觉得 DBA 拥有这些额外的密钥是有原因的（可能是为了让搜索更容易？）但我对数据库的了解还不够，无法确定。

【问题讨论】：

标签： .net sql-server entity-framework azure azure-sql-database

【解决方案1】：

糟糕的设计，有两个原因：

将有意义的值作为主键是一个错误的决定。您的 DBA 应该知道，如果某天项目名称发生更改，则需要对所有相关表进行表重建，因为不能只修改主键值。
您的 DBA 还应该知道这不是良好规范化的设计，因为所有这些键值都是多余的。归一化的想法是减少冗余。如果Area 需要知道它的Projects 名称，它应该加入Project。 RDBMS 对这些类型的反向连接进行了非常好的优化。

所有这些复合键都应该被删除。主键应该是与业务逻辑无关的 singular 值，因此它们可以是不可变的（所谓的 代理键 - 将这些视为 @ 是一种学术特权987654321@)。这是一个使用复合键编写连接的 PIA。即使使用为您生成查询的 EF，也更容易拥有单数主键。

如果任何字段组合应该是唯一的，则应应用唯一索引，可能是集群的。主键默认是聚集的，但是在设计表时可以选择另一个索引作为聚集索引。这是contemplate profoundly的东西。

【讨论】：

关于第 2 点：那么创建像上面的“SubArea”类这样的实体类是个好主意吗？我有一组子项（场景）和一个指向其父项（区域）的指针。然后，为了获得图中所示的层次关系，我需要创建连接吗？
是的，这绝对是我会做的。尽管您不应该像在 LINQ 中编写它们那样“创建连接”，但要使用您提到的导航属性。只有当性能明显受到影响时，您才可以考虑对树中较高的父级使用冗余外键（单个 Id 值）。

【解决方案2】：

EF6 代码优先方法是可能的。看看这个http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-inheritance-with-the-entity-framework-in-an-asp-net-mvc-application

【讨论】：

我不确定问题是否与继承有关，因为我没有继承任何表中的任何数据。这更像是一个 1:many 关系的问题。