I am looking for advice or alternatives on how to model the following relationships.
Consider:

And an application of said relations:

Mr. Warlord has many choices, however if a resource disappears, his choice cascade-dly removes. Now Firearms and Bullets are both resources. Firearms can use many kinds of bullets, (FMJ,HP,P+,Explosive?..). Bullets can also be used in a variety of firearms (AK,M60,M14). So I would also like to ensure that if a Bullet is no longer available, the aforementioned Firearm relationship would no longer exists, and vice-versa.
Hopefully my fantasy example of perk earning Warlords paints a clear picture.
Resources are abstract. Though they exist in the datastore for constraint purposes, I would never instantiate a generic resource. And I could have many more types (henchmen, helicopters, werewolves,...) each with quite different attributes. They exist in the first case to avoid a polymorphic foreign key situation with the ChoicesEarned.
You will notice that Resource Type 2 does not contain a Set<Type1>, but merely the reference to the (Long)ResourceId of some Firearm. (Bullets cannot hold firearms, even if the reverse is true, and for sake of argument, yes these magical guns can shoot many types of bullets).
Why do I have collections of ID's, not objects? Well If I add a type of bullet, it seems more efficient to add an Id reference to an association table than to retrieve the firearm and "add" a bullet object to it. That way too, when I retrieve a firearm object, I don't also retrieve all of the bullets it could possibly use. (Less memory overhead for all those objects, instead just a bunch of Ids).
So what was the question?:
1.) This doesn't seem like an uncommon pattern. Is there a better way to model it?
2.) Am I being an OOP heretic to use references instead of objects? Should I just use Objects?
My Main Problem
3.) If 1 and 2 aren't the case, How can I model this in JDO? I have experimented for a couple days and the problem I keep having is that JDO can't seem to recognize the relationship between the Sets of Longs. Every example I have found shows the use of Composition objects, not M-N attribute references. If I don't specify another persisted object there seems to be some confusion. An attribute of a persisted object doesn't seem to work.
UPDATE:
I received an answer from the DataNucleus forum today, Here is the thread
The problem was related to my Question #2 above. My attempt at saving some memory overhead was the source of my difficulties. I cannot establish a relationship between collections whose element types are not other persisted classes without jury-rigging. I will need to re-design a little bit.
SOLUTION:
See my Answer below
I appreciate everyone's input.
I don't know JDO so I am going to answer your question from the perspective of JPA and in a general way.
When it comes to mapping inheritance with an ORM you need to ask yourself the following questions.
1) Are you looking for ploymorphic query support. i.e. do you want to do a query for objects of type Resources and get back a list of objects of type Bullets and Fire arms.
If you don't need a polymorphic query you will want to use @MappedSuperclass which means that your base class contains annotations for mapping meta data which are inherited by the subclasses but the base class itself does not have an identity and therefore is not queryable but you can query for the sub classes.
If you do need polymorphic queries then you can have three possible table structures for mapping inheritance these are called strategies in JPA.
Each of those three inheritance mapping strategies have their pros and cons in terms of effort they put on the database. for example the single table with discriminator column would lead to a sparse table with lots of column but there are no joins required for a polymorphic query.
Many of the JPA books give a very good explanation of the tradeoffs between the three approaches, the important thing is to make sure you know what those trade offs are so you can pick the best approach for your app.
http://www.apress.com/9781430219569 has a decent discussion of the issues with mapping inheritance.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With