polymorphic association类似于外键或多对一关系,不同之处在于目标可能是多种类型之一(语言中的类,数据库中的表)。
我正在将已经使用多年的数据库设计从PHP移植到Java。在旧代码中,我已经滚动了自己的ORM,由于多种原因,它不是最佳的。尽管我可能稍后会开始调整,并可能最终自己重新实现,但现在我想在实体类上使用现成的ORM和JPA。
现在,我不知道如何在JPA中表达有关数据库布局的一件事:
我有一个Node
和Edge
表存储一个图形(DAG,如果有关系的话)。每个节点可以选择引用数据库中的另一个实体。这些实体可能在整个图形中被多次刷新,也可能存在“孤立的”实体,这对于用户来说是 Not Acceptable ,但至少保留一段时间可能是有意义的。
这些对象在继承等方面完全不相关,但是具有自然的层次结构,类似于Customer-> Site-> Floor-> Room。实际上,几年前,我只是从指向“父”对象的外键字段开始的。但是,这种层次结构不够灵活,因此开始崩溃。
例如,我想允许用户将文件夹中的对象分组,某些对象可以具有多个“父级”,并且关系会随着时间而变化。我需要跟踪过去的关系,因此图的edeg具有与之关联的时间跨度,该时间跨度表示从何时到该边缘有效的时间。
从节点到对象的链接存储在节点表的两列中,一列携带外表中的id,一列携带其名称。例如(省略了一些列):
table Node:
+--------+-------+----------+
| ixNode | ixRef | sRefType |
+--------+-------+----------+
| 1 | NULL | NULL | <-- this is what a "folder" would look like
| 2 | 17 | Source |
| 3 | 58 | Series | <-- there's seven types of related objects so far
+--------+-------+----------+
table Source (excerpt):
+----------+--------------------+
| ixSource | sName |
+----------+--------------------+
| 16 | 4th floor breaker |
| 17 | 5th floor breaker |
| 18 | 6th floor breaker |
+----------+--------------------+
与使用JPA可能会有不同的解决方案。我可以更改表布局或引入新表等内容。但是,我已经考虑了很多,因此表结构对我来说似乎还可以。也许还有我没有想到的第三种方式。
最佳答案
我认为您已经找到答案了。创建一个抽象类(@Entity或@MappedSuperclass),并使用不同的类型对其进行扩展。
这样的事情可能会起作用
@MappedSuperclass
@Inheritance(strategy=InheritanceType.TABLE_PER_CLASS)
public abstract class Edge {
// . . .
@OneToMany
Collection<Node> nodes;
}
@Entity
public class Source extends Edge {
}
@Entity public class Series extends Edge {
}
@Entity
public class Node {
// . . .
@ManyToOne
Edge edge;
}
我知道您可能不想暗示Source和Series之间的关系,但是扩展通用的抽象(无表)类是我想到的唯一可以做的方法。
InheritanceType.TABLE_PER_CLASS会将Source和Series保留在单独的表中(您可以使用SINGLE_TABLE来执行与上一个答案类似的操作)。
如果这不是您想要的内容,那么许多JPA提供程序都提供了一种可基于一组现有表创建映射的工具。在OpenJPA中,它称为ReverseMappingTool [1]。该工具将生成Java源文件,您可以将其用作映射的起点。我怀疑Hibernate或EclipseLink有类似的东西,但是您可以只使用OpenJPA,然后将实体定义与其他提供程序一起使用(据我所知,该工具不会生成任何OpenJPA特定的代码)。
[1] http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_pc_reverse