我正在寻找有关如何为以下关系建模的建议或替代方案。
考虑:
以及上述关系的应用:
先生。 Warlord 有很多选择,但是如果资源消失,他的选择就会级联地删除。现在枪支和子弹都是资源。枪械可以使用很多种子弹,(FMJ,HP,P+,Explosive?..)。子弹也可用于多种枪械(AK、M60、M14)。因此,我还想确保如果子弹不再可用,上述枪支关系将不再存在,反之亦然。
希望我幻想的赚取 Warlords 福利的例子能描绘出一幅清晰的画面。
资源是抽象的。尽管出于约束目的它们存在于数据存储区中,但我绝不会实例化通用资源。而且我可以有更多类型(心腹、直升机、狼人……),每种类型都有完全不同的属性。它们在第一种情况下的存在是为了避免 ChoicesEarned 的多态外键情况。
您会注意到资源类型 2 不包含 Set<Type1>
, 而仅仅是对 (Long)ResourceId
的引用一些枪支。 (子弹不能装枪支,即使反过来也是如此,并且为了论证,是的,这些神奇的枪支可以发射多种类型的子弹)。
为什么我有 ID 的集合,而不是对象?好吧,如果我添加一种子弹,那么将 Id 引用添加到关联表似乎比检索枪支并向其“添加”子弹对象更有效。同样,当我取回枪支对象时,我也不会取回它可能使用的所有子弹。 (所有这些对象的内存开销更少,而只是一堆 ID)。
那么问题是什么?
1.) 这似乎不是一种罕见的模式。有没有更好的建模方法?
2.) 我是 OOP 异教徒,使用引用而不是对象吗?我应该只使用对象吗?
我的主要问题
3.) 如果 1 和 2 不是这种情况,我如何在 JDO 中对其进行建模?我已经试验了几天,但我一直遇到的问题是 JDO 似乎无法识别 Long 集合之间的关系。我找到的每个示例都显示了 Composition 对象的使用,而不是 M-N 属性引用。如果我不指定另一个持久对象,似乎会有些困惑。持久对象的属性似乎不起作用。
更新:
我今天收到了 DataNucleus 论坛的回复,Here is the thread
这个问题与我上面的问题 #2 有关。我试图节省一些内存开销是我遇到困难的根源。 如果没有陪审团,我无法在元素类型不是其他持久化类的集合之间建立关系。我需要重新设计一点。
解决方案:
看下面我的回答
我感谢大家的意见。
最佳答案
我不了解JDO,所以我将从JPA的角度和一般的方式回答你的问题。
在使用 ORM 映射继承时,您需要问自己以下问题。
1) 您是否正在寻找多态查询支持。即您是否要查询资源类型的对象并取回子弹和火器类型的对象列表。
如果您不需要多态查询,您将希望使用@MappedSuperclass,这意味着您的基类包含用于映射元数据的注释,这些元数据由子类继承,但基类本身没有身份,因此是不可查询,但您可以查询子类。
如果您确实需要多态查询,那么您可以使用三种可能的表结构来映射继承,这些在 JPA 中称为策略。
- 每个具体类的表格
- 带有鉴别器列的单个表
- 继承层次结构中每个类一个表(你在问题中有什么)
这三种继承映射策略中的每一种都在它们对数据库所做的努力方面各有利弊。例如,具有鉴别器列的单个表将导致具有大量列的稀疏表,但多态查询不需要连接。
许多 JPA 书籍都很好地解释了这三种方法之间的权衡,重要的是确保您知道这些权衡是什么,以便您可以为您的应用选择最佳方法。
http://www.apress.com/9781430219569对映射继承问题进行了很好的讨论。
关于java - 将继承类型之间的关系建模为 ORM,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9440043/