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

Question

我在弄清楚我应该如何对这种关系层次结构建模时遇到了很大的问题，我希望有人能给我一个建议，并指出我必须使用FluentAPI进行的任何特殊配置。

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

接下来，我想要有一个“客户”的概念，它是系统中有一些其他数据的人，比如CustomerNumber字符串。

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

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

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

Answer 1

我建议使用如下的数据库结构：

​

​

Customer/Person:

我没有将Customer视为Person的特例，因为当您的客户第一次成为企业或其他类型的组织时，它就会崩溃。

如果您将Customer本身视为一种实体类型，并允许它包含一个或多个人员，那么您的优势在于能够将人员作为个人进行跟踪，包括他们的所有关系，一次且只有一次-即使他们是您的单独客户，也可以作为企业或其他组织的一部分。

对于许多客户来说，Commercial_Relationship中只有一条记录，这很好，但该模型提供了灵活性，可以只跟踪每个人一次，即使他们在不同的上下文中与您进行商业交易。

例如，我在史泰博买了钢笔，因为我有时家里需要一支钢笔。然而，我有时也会在史泰博买钢笔，因为我的办公室需要一支钢笔。我的会计让我使用不同的信用卡来支付这些个人和业务费用，以便将两者清楚地区分开来。然而，我很高兴我没有收到来自Staples的两组垃圾邮件，因为我从他们那里购买了两种不同的上下文。

个人关系：

这只是两个Person记录之间的多对多关系。所需要的只是一个交叉点实体类型。但是，请注意，这种关系的命名通常是定向的。在某些情况下，无论您正在遍历关系的哪个方向，都只需要一个名词。鲍勃是比利的朋友，比利是鲍勃的朋友。然而，Bob是Sally的父亲，但Sally是Bob的女儿(或孩子，等等)。因此，Personal_Relationship需要两个描述，这取决于您要遍历关系的方向。