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

[Byron Estes]

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,

[David Jordan]

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]

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]

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]

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