sql - 每个子类的表与 hibernate 中每个具体类的表？

Question

在大多数 Web 应用程序中，我看到了一个基类，它包含公共(public)属性和扩展基类的许多子类。所以我的问题是我们应该在 中采用哪种策略？每个子类的表与每个具体类的表 .我个人认为我们应该为每个子类选择一个表，因为将来如果我们想引入公共(public)列，我们可以在一个地方进行，但在具体类的情况下，我们必须在多个表中进行。 对？

但是是的，如果我们想从所有子表中获取所有细节，我认为 每个具体类别的表格 会有帮助因为我们必须简单地合并所有表中的记录，但在 的情况下每个子类的表与联合一起，我们必须引入与父表的联接，这将更加昂贵。 对？

Answer 1

您可能对 JPA 2.0 specification 的第 2.12 节“继承映射策略”感兴趣。 ，因为它总结了所有可能的继承类型以及它们的优缺点。让我拿出最有趣的片段:

2.12.1 每类层次结构单表策略

This mapping strategy provides good support for polymorphic relationships between entities and for queries that range over the class hierarchy. It has the drawback, however, that it requires that the columns that correspond to state specific to the subclasses be nullable.

2.12.3 每个具体类的表策略

This strategy has the following drawbacks:
- It provides poor support for polymorphic relationships.
- It typically requires that SQL UNION queries (or a separate SQL query per subclass) be issued for queries that are intended to range over the class hierarchy.

2.12.2 加入子类策略

It has the drawback that it requires that one or more join operations be performed to instantiate instances of a subclass. In deep class hierarchies, this may lead to unacceptable performance. Queries that range over the class hierarchy likewise require joins.

此外，如果您打算与 JPA 兼容，请记住 JPA 提供程序 不必支持 TABLE_PER_CLASS策略类型。

I personally feel we should go for table per subclass because in future if we want to introduce the common column we can do it at one place but in case of concrete class we have to do it in multiple tables.

没错，但 JOINED 策略也为您提供相同的功能，并允许在一个表中指定公共(public)属性。

希望有帮助!