在大多数 Web 应用程序中，我看到一个基类包含公共属性和扩展基类的多个子类。所以我的问题是我们应该在每个子类的表与每个具体类的表中采用哪种策略。我个人认为我们应该为每个子类选择一个表，因为将来如果我们想引入公共列，我们可以在一个地方进行，但在具体类的情况下，我们必须在多个表中进行。 对吗？
但是，如果我们想从所有子表中获取所有详细信息，我认为 每个具体类的表 会很有帮助因为我们必须简单地合并所有表中的记录，但在 的情况下每个子类的表以及联合我们必须引入与父表的连接，这将更加昂贵。对吗？
【问题讨论】：
The Object-Relational Impedance Mismatch
在对象模型中，在创建对象时，我们可能需要使用继承，即泛化如下：
在关系模型中，上述泛化（不是关联，即一对一或多对多）在Hibernate ORM中可以通过以下三种继承映射策略实现：
在这个策略中，我们可以将整个层次结构映射到一个表中，这里我们使用了一个更多的鉴别列，即 TYPE。
在此策略中，表是按类创建的，但通过外键关联。所以没有重复的列。
在此策略中，表是按类创建的，但通过外键关联。所以没有重复的列。
【讨论】：
您可能对JPA 2.0 specification 的第 2.12 节“继承映射策略”感兴趣，因为它总结了所有可能的继承类型以及它们的优缺点。让我挑出最有趣的片段：
2.12.1 每类层次结构单表策略
这种映射策略为多态提供了很好的支持 实体之间的关系以及范围在 类层次结构。然而，它有一个缺点，它需要 对应于子类特定状态的列是 可为空。
2.12.3 Table per Concrete Class 策略
这种策略有以下缺点：
- 它为多态关系提供了较差的支持。
- 它通常要求为旨在跨越类层次结构的查询发出 SQL UNION 查询（或每个子类的单独 SQL 查询）。
2.12.2 加入子类策略
它的缺点是需要一个或多个连接操作 执行以实例化子类的实例。在深课 层次结构，这可能会导致不可接受的性能。查询 类层次结构上的范围同样需要连接。
此外，如果您打算与 JPA 兼容，请记住 JPA 提供程序不必支持 TABLE_PER_CLASS 策略类型。
我个人认为我们应该为每个子类选择表，因为在 未来如果我们想引入通用列，我们可以一次性完成 地方，但在具体课程的情况下，我们必须多次这样做 表格。
没错，但 JOINED 策略也为您提供了相同的功能，并允许在一个表中指定公共属性。
希望有帮助！
【讨论】：
Animal -> [Dog, Cat] 层次结构。在singleTable 中，您在一个表中拥有所有类型 - 当有人执行SELECT Animal a... 时无需进行连接。如果你有joinedStrategy，那么你需要在表上进行 JOIN（因为每个子类都在不同的表中），但你仍然在一个表（动物）中有一个共同的属性。但是，在concreteTable 策略中，每个类都在单独的表中，因此选择所有动物将需要单独访问所有表。希望有帮助！
Animal 实例，而您并不关心将返回它的哪个子类。您甚至可以使用Animal 的一些通用属性对其进行过滤——再一次，您并不关心将返回哪些子类。这就是所谓的polymorphic query。