aspose file tools*
The moose likes JDBC and the fly likes This is for David and Craig (co-authors of Java Data Objects) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "This is for David and Craig (co-authors of Java Data Objects)" Watch "This is for David and Craig (co-authors of Java Data Objects)" New topic
Author

This is for David and Craig (co-authors of Java Data Objects)

Byron Estes
Ranch Hand

Joined: Feb 21, 2002
Posts: 313
David/Craig,
I'm sure you have worked with and continue to use technologies (EJB, JDBC with static sql and/or stored procedures) other than JDO (or in conjunction with JDO) on various projects. Could you spend a couple of minutes explaining what you look for during design that leads you to select one persistance method/technology over the others. In some cases, it may be purely stylistic, but I expect that you can lend some insight that may be helpful to the rest of us as we evaluate our options in light of our project requirements.
Regards,


Byron Estes<br />Sun Certified Enterprise Architect<br />Senior Consulant<br />Blackwell Consulting Services<br />Chicago, IL<br /><a href="http://www.bcsinc.com" target="_blank" rel="nofollow">www.bcsinc.com</a>
David Jordan
Author
Ranch Hand

Joined: Jun 14, 2003
Posts: 66
Do I have an application that can benefit from an object model, where I can benefit from representing my model as a set of inter-related Java classes that require a lot of Java computations? If so, use JDO.
Do I have a data model and transaction mix that are a great match for expressing everything in SQL, with no real need to represent data in my application? Do I make use of advanced SQL features like union, group by, etc. If so, use JDBC.
If I need each individual object to be accessible remotely in the network, then I would consider EJB, though there are also other technologies that can also be used.
The general concensus in much of the EJB community is that you should have remote applications only interact directly with session beans, let the session beans have the direct interactions with the entity beans. This is largely done for performance reasons. But if you end up having a session bean interact with entity beans that are local in the same EJB server, using JDO objects instead of entity beans is definitely going to be simpler and will likely have better performance.
Byron Estes
Ranch Hand

Joined: Feb 21, 2002
Posts: 313
David,
Thanks for replying.
You said pretty much what I expected.
Although I've never used JDO (yet), prior to EJB (...and even after) I've used other data persistance abstactions (home grown and packaged) and straight JDBC and the choices I've made to employ them are pretty well in line with your reasoning.
I'll add the following:
JDO and similar frameworks
- well defined problem domain
- access paths/content are fairly rigid
- use for situations that are heavy CRUD.
JDBC
- not a well defined problem domain
- acces paths/content are flexible/fluid.
- Mostly reads for reports, utilizing as you said some of the more complex SQL functions we all know and love.
EJB
Nothing really to add. Couldn't agree more here. If you need a trasaction that crosses multiple databases/other data transaction participants you can still use JDBC or JDO but establish the transaction context through a session bean.
I've downloaded Chapter 1 of your book, I look forward to reading on the train. I love O'Reilly books in general due to the format, and the strength of the authors they tend to select.
Thanks again!
[ June 17, 2003: Message edited by: Byron Estes ]
[ June 17, 2003: Message edited by: Byron Estes ]
David Jordan
Author
Ranch Hand

Joined: Jun 14, 2003
Posts: 66
I agree with you.
SQL is great for doing truly adhoc queries where you can establish relationships and criteria dynamically at run time and let the join capabilities of the RDBMS establish the relationships.
JDO works best when you have a model with known static relationships among your entities. JDO's query language can navigate these known relationships, but it cannot do adhoc joins ala SQL. It completely depends on your data model, types of transactions/access patterns to decide which is most appropriate.
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 29253
    
140

Also JDBC is great for pulling in a large amount of data.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: This is for David and Craig (co-authors of Java Data Objects)
 
Similar Threads
Java Data Objects by David Jordan and Craig Russell
JDO
JDO and transactions
JDO & EJBs
Hibernate, JDO 2.0 and EJB 3.0