I was getting curious about role of entity beans in a data centric application. When there are alot of joins, entity beans looks very costly in terms of resource usage. Previously the job that was done by one query will now require calls to serveral entity beans. What should we do? Should we design the db to make it look like more of objects than relational. Please do comment on this.
- Posted by: Muhammad Hassan
- Posted on: December 10 2001 06:01 EST
Thanks in advance
Entity beans (especially pre EJB 2.0) are very bad at doing joins across multiple tables. EJB2.0 is better and some tools like Toplink and Persistence offer much better Object -> Relational mapping capabilities.
In the most recent EJB 1.1 projects I did we ended up using BMP and writing the SQL either in the Entity Bean or in the Stateless Session Bean (complex joins ended up in Stateless Session Beans). One good pattern for this case is "The Aggregate Entity" pattern.
In EJB2.0 the "Aggregate Entity" pattern is less useful due to new developments in Object -> relational mappings and local interfaces.
As for the database question should your design be more classic 4NF or object oriented it depends on who designs it? DB people will push for a completely normalized db while OO people will tend to go to a much more simple mapping of Object to table. Of course as with everything the answer lies somewhere in the middle.
If you are using Data just for readonly purpose, whats about creating DB-Views; the join will then be handeled by the View and not by the EJB...
RDBMS is very matured and around for more than 30 years. I prefer having a sound database design.
I agree with David. EJB 2.0 greatly reduces use of BMP. It is very easier to use CMP and impelement the joins using CMR's. Try adhering to standard. J2EE platform is highly scalable and you can add hardware when the performance degrades.
I would not go for 4NF, it is too much. 4NF design go further away from the Object Orientation. A good 3NF should be good for most of the application.
As David says the answer lie same where between.