a modelling problem

[Karthik Guru]

This is somethign that i faced earlier..
let me describe the problem statement anyways.
.............................
In a system, the smallest unit that can be sold is a "Catalog Item".
Then there are Bundles that are a collection of Catalog Items.
Now since i have to sell the items i need to have a price for them.
A "Price List" can be defined that spans a given start date through an end date. A price list has a name and status (indicating whether it is active/ not).
But wait, I can have various "Price List Versions" for this PriceList. A Catalog Item can have only one price for a given "Price List Version".
So,in essence, a price list consists of multiple price list versions that in turn define a price for multiple catalog items.
the non-functional aspects are :
There can be 10000s of catalog items.There w'd be atleast one active price list.Each price list might have close to say 5 price list versions. And the worst case is that there might be a price defined for every item / version.
Now how w'd the relational and object model look like for this problem ?.
I was wondering as to how many tables and beans would you have at the minimum to model this scenario.
Anyways, if my description was'nt clear,
here is what I have identified :
1.CatalogItem
2.PriceList
3.PriceListVersion
4.CatalogItemPrice ( which represents an Association class between a Version and an Item , basically the version-item combination is unique and there is a price defined @ that level)
and
5 Bundle
Bundle has 1 --> many (bi-directional) relationship with CatalogItem
PriceList has 1 --> many (bi-directional) relationship with PriceListVersion
PriceListVersion will have to shoulder the responsibility of returning all the CatalogItemPrices associated with it.
I have modelled the responsibilities as CMRs.
The problem is I have ended up with 5 tables and 5 entity beans!.
If it goes on like this, I would probably end up with an entity bean for every table that is there in the system!.
I guess Lasse pointed out that Core J2ee patterns book says that this way of modelling is wrong! How do we approach such scenarios?.

[mathew mathews]

First of all can you tell me how you landed on usage of EJB for this..?
That is the basic thing you should know for first

[Lasse Koskela]

Karthik, there isn't necessarily nothing wrong with you ending up with a 1-to-1 mapping between entity beans and database tables.
Check out http://www.onjava.com/lpt/a/2697 for an article on entity bean table mapping for object hierarchies.

[Karthik Guru]

Originally posted by mathew mathews:
First of all can you tell me how you landed on usage of EJB for this..?
That is the basic thing you should know for first

Why Entity beans? a good question, though i think it does'nt have much relevance with what i asked in the post. My question was more of whether am modelling it in a correct way. Object-relational mapping / modelling has nothing to do with EJB. We c'd have used some other tools / JDO etc to achieve the same and c'd have had better performance levels.
To answer your question:
1. We wanted someone to handle persistence transparently to us. We thought we were not good @ JDBC :-),just kidding.
2. It is always easier to code with domain entities in mind.
For eg: we had entities like items, bundles, price lists.
You always like to talk the business language right? So when somebody says "a bundle can have n catalog items", it automatically translates to
bundle.setCatalogItems(collectionOfItems);
in code. I dont have to write SQls to do this for me.
3. We Did NOT require many of the services provided by Entity beans.
But still we went ahead and used it. For eg we did'nt use declarative security on the methods, declarative Transactions ,well, yes we did.
But i guess we w'd have been ok with transactions gettign applied @ the session facade level. I dont think we really needed transactions @ a very corase grained level. Either way, we had marked our entity beans with
"Required" trans attribute and session facade was starting a new transaction
and it w'd have extended to the beans as well.
4. We thought that if the container can manage relationships as well, it w'd be cool and EJB2.0 provides that.
5. Since we used EJBLocal objects for all our entities, we thought we w'd not run into typical entity bean performance problems since we thought it is optimized @ various levels. But we were wrong. We probably relied a lot on entity beans to solve some business requirements. But then we did re-write some part of the code with plain old SQls.
6. We w'd have gone with JDO, but our company standard software stack does not support this. We are a product company. Tomorrow our products might have to talk to existing products or they might interact with ours. A customer might be willing to buy this with other offerings that we have.
We cannot ship it with a different software stack. Moreoever weblogic6.1 / websphere 4.0 ( which was a part of our standard stack then did'nt not support JDO).Not sure why?
These are the various reasons that i can think of right now as to why we went with Entity beans.

[Lasse Koskela]

Karthik, are you sure that "not supporting JDO" didn't just mean "we don't ship a JDO implementation with our application server"? Generally you should be able to use any JDO implementation with any J2EE appserver (the J2EE server doesn't know that your application contains JDO-enhanced .class files or the JDO vendor's configuration files).

[Karthik Guru]

Originally posted by Lasse Koskela:
Karthik, are you sure that "not supporting JDO" didn't just mean "we don't ship a JDO implementation with our application server"? Generally you should be able to use any JDO implementation with any J2EE appserver (the J2EE server doesn't know that your application contains JDO-enhanced .class files or the JDO vendor's configuration files).

Yes i understand what you are saying, that you run the code through an enhancer which in turn instruments the byte code and not the source code.
I think even the objects that we write to a *great* extent are independent of the JDO API classes?. I mean it just looks like plain java objects unlike entity beans?
We w'd have used JDO had weblogic/websphere provided an implementation. We were not allowed to buy an implementation from any other JDO Vendor. IPlanet I guess provides one but unfortunately is not a part of our standard stack.

[Lasse Koskela]

Yes i understand what you are saying, that you run the code through an enhancer which in turn instruments the byte code and not the source code.
I think even the objects that we write to a *great* extent are independent of the JDO API classes?. I mean it just looks like plain java objects unlike entity beans?

Your Java code doesn't know anything about the particular JDO implementation. It only uses a couple of interfaces from the JDO API. I am still very green with JDO so don't ask me for more details

[Pradeep bhatt]

Lasse,
Have you started reading the JDO book that you won?

[Lasse Koskela]

Have you started reading the JDO book that you won?

It is undergoing my multi-tasking process as we speak
So far it hasn't received too much CPU time but it's not starving either...