使用共同点建模实体：超类型/子类型？

Question

我将使用LLBLGen来生成模型，但是我不想通过使用它所具有的任何内置继承工具来解决我的设计问题。无论OR/M工具如何，我都希望模型有意义。

所以，我有几种不同的实体可以有地址，每个实体可以有多个地址（主要的，邮件等）。

选项1，使用超类型/子类型（如果你知道这种方案的确切名称，这将是有益的）

表： 的EntityType [EntityTypeID，EntityTypeName] （说，公司= 1， 雇员= 2，AnotherEntity = 3）

实体：[ENTITYID，EntityTypeID，OriginID]：EntityTypeID =>的EntityType

公司：[CompanyID，公司名称，...]

雇员：雇员，姓，...]

地址类型：[AddressTypeID，AddressTypeName]（说，小学= 1，邮件= 2，等等）

地址：[AddressID，AddressTypeID，ENTITYID， StreetAddress1，...]：AddressTypeID =>地址类型，ENTITYID =>实体

这样的工作的方式是创建的任何公司或员工之前，实体唱片则必须创建具有适当的EntityType填写。然后创建公司或员工，并将Entity.OriginID设置为公司或员工的ID。现在，地址记录将属于将“绑定”到具体实体的实体记录，以查看EntityTypeID和OriginID。

我有点担心这将需要所有的连接。更有甚者，我有点担心这在我的ORM工具（LLBLGen）中会很笨拙。

选项2，这有点采取选项1.我觉得可能是雪上加霜，但包括它只是相同的：

表：

的EntityType：[EntityTypeID，EntityTypeName]（说，公司= 1，雇员= 2，AnotherEntity = 3）

实体：[ENTITYID，EntityTypeID]：EntityTypeID =>的EntityType

公司：[CompanyID，ENTITYID，公司名称，...]：ENTITYID =>实体

雇员：雇员，ENTITYID，姓，...]：ENTITYID =>实体

地址类型：[AddressTypeID，AddressTypeName]（说，小学= 1，邮件= 2，等等）

地址：AddressID，AddressTypeID，ENTITYID，StreetAddress1，...] AddressTypeID =>地址类型，ENTITYID =>实体

这会工作类似于选项1，在一个公司或员工，一个实体记录将首先创建，适当地设置EntityType。然后，将创建公司或员工记录，并且之前创建的实体记录的实体ID将在公司或员工记录本身上设置。地址将被绑定到实体本身。但是，这看起来很奇怪，因为这会处理Address记录，例如Company和Employee记录，即它们持有EntityID，但该引用意味着EntityID在Company和Employee表中引用的内容不同。

这似乎有点恶化。它与第一个问题几乎有相同的问题，但它也使得模式不那么直观，我想。

在这两种情况下，您都需要使用某些唯一约束，例如在公司表中（EntityID在公司表中应该是唯一的）。但是，您需要执行其他程序检查以防止公司和员工记录指向相同的实体记录。我不知道像LLBLGen这样的工具是否可以通过智能地处理EntityTypeID值来对Option 1做任何“魔术”。

所以，选项3非常简单：

表：

公司：[CompanyID，公司名称，...]

雇员[雇员，名字，...]

AddressType：[AddressTypeID，AddressTypeName]（Say，Primary = 1，Mailing = 2等）

CompanyAddress：[Compan yAddressID，AddressTypeID，CompanyID，StreetAddress1，...]： AddressTypeID =>地址类型， CompanyID =>公司

EmployeeAddress：[EmployeeAddressID，AddressTypeID，雇员，StreetAddress1，...]： AddressTypeID =>地址类型， EmployeeID =>员工

这使得连接更容易处理。但是，我不认为这是可行的。我有很多实体。我不仅拥有很多实体，而且拥有很多可以拥有地址的实体。此外，这个“地址”的东西只是一个例子，我有许多其他类似的地址的东西。我不认为为每个人创造一张桌子都会在发展方面产生很大的影响。另外，我确定我可以让我的ORM让我使用代码将所有不同的地址作为同一个基本的“地址”类型来处理，但是我再也不想依赖ORM可以做的技巧。

那么，这是超级类型/子类型的东西一个好主意（我怀疑不是）？如果是这样，有没有更好的方法去实现它。如果不是，有什么更好的选择。

Answer 1

该主题已经在网上进行了广泛的撰写。查阅“泛化专业化数据建模”或“泛化专业化数据库设计”。

就你而言，公司和员工是具有地址的专门实体。

在其他一些情况下，卡车和汽车可能是专用车辆。在另一个案例中，学生和校友可能是专门的社区成员。

我可以在这里总结一下，但你最好从源头上获益。

Answer 2

这个问题有点罗嗦。你可能应该尝试把它修剪到基本要素。我比JPA更熟悉JPA（在ORM空间中），但JPA有这个概念，它被称为映射超类（继承策略）。这完全有效，值得考虑。

在一个系统中，我设计了许多实体（公司，人员，合伙人，信托等）具有共同实体（例如法定名称）和相关实体（例如地址，联系方式）超类型，这与你要去的地方有些相似。

是的，你确实有一个类型列（在超类型中）。在JPA中称为鉴别器列。