多态 ORM 数据库模式

Question

我记得很久以前，当我在摆弄 Java ActiveObjects ORM 时，我遇到了它声称支持的数据库模式。

然而，通过搜索总体思路很难找到模式的名称，因此如果有人能给我这个模式的名称，以及关于使用它的“干净”的一些想法，我将非常感激。

---

该模式定义如下：

Table:
  reference_type <enum>
  reference      <integer>
  ...

... 其中字段 reference_type 的值将确定所引用的类型（以及表）。因此：

User:
  location_type <l&l, address, city, country>
  location      <integer>
  ...

...根据 location_type 字段的值，外键 location 将引用 l&l、<代码>地址、城市或国家表。

Answer 1

您很难找到它，因为它不是真正的（在广泛采用和鼓励的意义上）数据库设计模式。

远离这样的模式。虽然 ORM 使将数据库表映射到类型变得更容易，但表不是类型，反之亦然。虽然不清楚您所描述的模型应该做什么，但您不应该将列用作多个表的假外键（当我说“假”时，我的意思是您正在存储一个简单的标识符值对应于另一个表的主键，但您实际上无法将该列定义为外键）。

对数据库进行建模以表示数据，对对象进行建模以表示流程，并使用 ORM 和中间层进行转换；不要尝试将数据库推送到您的代码中，也不要将您的代码推送到数据库中。

编辑回复评论

您正在混合数据库和面向对象的术语；虽然我不熟悉您用来定义该函数的语法，但我假设它是 User 类型上名为 getLocation 的实例函数，不带任何参数并返回一个 Location 对象。数据库不支持实例（或任何基于类型的）函数的概念；关系数据库可以具有用户定义的函数，但这些是简单的过程函数，它们接受参数并返回值或结果集。除了您可以在函数体内使用它们这一事实之外，它们不以任何方式对应于特定的表或字段。

话虽这么说，这里有两个问题需要回答：如何执行您所要求的操作，以及什么可能是更好的解决方案。

对于您所问的问题，听起来您有一个超类型-子类型关系，这是一种标准的数据库设计模式。在本例中，您有一个表示父级的超类型表：（

Location
---------------
LocationID (PK)
...other common attributes

请注意，为了简单起见，我使用 LocationID；您应该具有更具体和逻辑的属性来定义主键，如果可能的话）

那么您有一个或多个定义子类型的表：

Address
-----------
LocationID (PK, FK to Location)
...address-specific attributes

Country
-----------
LocationID (PK, FK to Location)
...country-specific attributes

如果Location的特定实例只能是子类型之一，那么您应该向父表添加一个鉴别器值（Location >Location），指示它对应的子类型。您可以使用 CHECK 约束来确保给定行的该字段中只有有效值。

但最终，听起来混合方法可能会更好。从我看来，您基本上代表了两种不同类型的位置：

• 基于坐标的位置 (L&L)
• 基于市政/邮政/等的位置（国家/地区、城市、地址），其中每一个都只是一个上一个的更具体版本

鉴于此，一个简单的模型将如下所示：

Location
------------
LocationID (PK)
LocationType (non-nullable) ('C' for coordinate, 'P' for postal)

LocationCoordinate
------------------
LocationID (PK; FK to Location)
Latitude (non-nullable)
Longitude (non-nullable)

LocationPostal
------------------
LocationID (PK, FK to Location)
Country (non-nullable)
City (nullable)
Address (nullable)

现在剩下的唯一问题是我们有可为空的列。如果您想让查询保持简单，但受到人们对保留可为空列的批评（合理！），那么您可以保持原样。如果您想要使用大多数人认为设计更好的数据库，您可以将两个可为空的列迁移到 6NF。这样做还会产生一个很好的副作用，让我们可以更好地控制这些字段的填充方式，而无需执行任何额外操作。

我们的两个可为 null 的字段是 City 和 Address。我假设没有 City 的 Address 是无意义的。在本例中，我们从 LocationPostal 表中删除这两个属性，并创建另外两个表：

LocationPostalCity
------------------
LocationID (PK; FK to LocationPostal)
City (non-nullable)

LocationPostalCityAddress
-------------------------
LocationID (PK; FK to LocationPostalCity)
Address (non-nullable)

Answer 2

在我看来，城市和国家将成为地址表的一部分，并且L＆L不会与地址相互排斥（你可能两者都有......），所以，为什么要限制自己像这样对待一个或另一个？

此外，这会阻止 location 列强制执行引用完整性，不是吗，因为它并不总是引用同一个表？