0

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

所以，我有几种不同类型的实体，它们可以有地址，每个实体都可以有多个地址（主要地址、邮寄地址等）。

选项 1，使用超类型/子类型（如果您知道此类方案的确切名称，那将很有帮助）

表：EntityType [EntityTypeID, EntityTypeName]（例如，Company=1，Employee=2，AnotherEntity=3）

实体：[EntityID，EntityTypeID，OriginID]：EntityTypeID=>EntityType

公司：[公司 ID、公司名称、...]

员工：[员工ID，名字，...]

AddressType：[AddressTypeID, AddressTypeName]（例如，Primary=1，Mailing=2 等）

地址：[AddressID, AddressTypeID, EntityID, StreetAddress1, ...] : AddressTypeID=>AddressType, EntityID=>Entity

这样做的方式是，在创建任何 Company 或 Employee 之前，必须创建一个 Entity 记录并正确填写 EntityType。然后创建 Company 或 Employee 并将 Entity.OriginID 设置为 Company 或 Employee 的 ID。现在，地址记录将属于实体记录，这些记录将“绑定”到具体实体查看 EntityTypeID 和 OriginID。

我有点担心这需要的所有连接。更重要的是，我有点担心这在我的 ORM 工具 (LLBLGen) 中会很笨拙。

选项 2，这是对选项 1 的一种看法。我认为可能更糟，但包括它是一样的：

表：

EntityType：[EntityTypeID, EntityTypeName]（比如，Company=1，Employee=2，AnotherEntity=3）

实体：[EntityID，EntityTypeID]：EntityTypeID=>EntityType

公司：[CompanyID, EntityID, CompanyName, ...] : EntityID=>Entity

员工：[EmployeeID，EntityID，FirstName，...]：EntityID=>Entity

AddressType：[AddressTypeID, AddressTypeName]（例如，Primary=1，Mailing=2 等）

地址：[AddressID, AddressTypeID, EntityID, StreetAddress1, ...] AddressTypeID =>AddressType, EntityID=>Entity

这将类似于选项 1，因为对于公司或员工，将首先创建实体记录，并适当地设置实体类型。然后，将创建 Company 或 Employee 记录，并且先前创建的 Entity 记录的 EntityID 将设置在 Company 或 Employee 记录本身上。该地址将与实体本身相关联。然而，这似乎很奇怪，因为这会将地址记录视为公司和员工记录，即它们持有一个实体ID，但该引用意味着与公司和员工表中实体ID 引用的不同。

这似乎有点糟糕。它与第一个问题几乎相同，但我认为它也使模式不那么直观。

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

因此，选项 3 很简单：

表：

公司：[公司 ID、公司名称、...]

员工 [EmployeeID, FirstName, ...]

AddressType：[AddressTypeID, AddressTypeName]（例如，Primary=1，Mailing=2 等）

CompanyAddress: [CompanyAddressID, AddressTypeID, CompanyID, StreetAddress1, ...] : AddressTypeID=>AddressType, CompanyID=>Company

EmployeeAddress: [EmployeeAddressID, AddressTypeID, EmployeeID, StreetAddress1, ...] : AddressTypeID=>AddressType, EmployeeID=>Employee

这使得连接更容易处理。但是，我不认为这真的可行。我有很多实体。我不仅有很多实体，而且我有很多可以有地址的实体。另外，这个“地址”只是一个例子，我还有很多其他类似于地址的东西。我不认为为每个人创建一个表格会在开发方面进行扩展。另外，我确信我可以让我的 ORM 让我使用代码将所有不同的地址视为相同的基本“地址”类型，但是，我不想依赖 ORM 可以做的技巧。

那么，这种超类型/子类型的东西是个好主意吗（我怀疑不是）？如果是，是否有更好的方法来解决它。如果没有，有什么更好的选择。

4

2 回答 2

0

这个问题有点啰嗦。您可能应该尝试将其精简为基本必需品。我比您使用的工具（在 ORM 空间中）更熟悉 JPA，但 JPA 有这个概念，它被称为映射超类（继承策略）。这是完全有效的，值得考虑。

在一个系统中，我设计了许多实体（公司、个人、合伙企业、信托等），它们有共同的实体（例如法定名称）和相关的实体（例如地址、联系方式），因此很自然地有一个共同的 Party 超类型，即有点类似于你要去的地方。

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

于 2009-01-26T10:00:18.833 回答
0

该主题已在网络上广泛讨论。查找“泛化专业化数据建模”或“泛化专业化数据库设计”。

在您的情况下，公司和员工都是具有地址的专业实体。

在其他情况下，卡车和汽车可能是专用车辆。在另一种情况下，学生和校友可能是专业的社区成员。

我可以在这里总结一下，但你最好了解来源。

于 2009-01-26T14:14:25.607 回答