EF6 - 为客户管理系统建模复杂的层次结构

Question

我遇到了重大问题，我应该如何模拟这种关系层次结构，并希望有人能够提出建议，并指出我需要做的任何特殊配置FluentAPI。

基本上，我正在创建一个客户管理系统。我希望基础对象是一个“Person”，它将保存一个id，名称，联系信息等。

接下来，我想要有一个“Customer”的概念，它是系统中的Person还有一些其他数据，比如一个CustomerNumber字符串在上面。

然后，我希望每个人都有一个其他人是“亲属/朋友”的集合。它还需要指定关系的类型（兄弟，父亲等）。

因此，基本上，它归结为拥有一个庞大的人员数据库的目标 - 任何人都可能成为客户，也可能不是客户，并且任何人都可以设置为任何其他人员/客户的亲友整个系统。一个人可以有无限数量的亲戚/朋友，并且可以是任何数量的其他人的亲戚/朋友（或根本没有）。

我希望我已经解释得很好。我以几种不同的方式（从使用继承，直接为外键建模连接表）对此进行了建模，到目前为止，在生成模型时没有任何结果与正确的数据库结构有关。

Answer 1

我会建议数据库结构是这样的：

客户/联系人：

我没有处理过的Customer作为Person一个特例，因为分崩离析您的第一次客户是企业或其他类型的组织。

如果您将Customer作为实体类型进行单独处理并允许其包含一个或多个人，那么您可以将个人作为个人（包括他们所有的关系）一次又一次地跟踪其优势 - 即使他们是您的客户，也可以共同作为企业或其他组织的一部分。

对于很多客户来说，在Commercial_Relationship中只有一条记录，这很好，但该模型提供了灵活性来追踪每个人一次，即使他们在不同的环境中处理您的商业情况。

例如，我在斯台普斯购买笔，因为我有时在家需要一支笔。不过，我有时也会在斯台普斯购买笔，因为我在我的办公室需要一支笔。我的会计师使我使用不同的信用卡来支付这些个人和业务费用，以便使两者明显不同。不过，我很高兴我没有从斯台普斯那里得到两套垃圾邮件，因为我在两种不同的环境下向他们购买。

人际关系：

这根本就是两个Person记录之间的许多一对多的关系。所有需要的是一个交集实体类型。但是请注意，命名这种关系往往是有方向性的。在某些情况下，只需要一个名词，而不管你穿过关系的方向。鲍勃是比利的朋友和比利是鲍勃的朋友。然而，Bob是Sally的父亲，但Sally是Bob的女儿（或儿童等）。因此，Personal_Relationship需要两个说明，具体取决于您穿过关系的方向。