Subject: Re: Open Source JDO Implementation??
From: Vic Cekvenich <[EMAIL PROTECTED]>
 ===
DB performance depends (among other things) on SQL execution path chosen 
by the optimizer. A SQL command string can be customized to optimize 
that SQL and have it "force" it to go a cretain way on joins. If you 
have a complex joing with many tables, this is a critical performance 
that can impact it order of magnitude. Sometimes propriatory, sometime 
stored procedures. Each extra join can be exponential. (Some clients do 
16 way joins, no lie)

So the level of abstraction will be expensive here. If DB is the 
bottleneck, than you need to be "closer to the metal".

On the design side, you can't model certain things like employes and 
managers. (Manager is an employee, therfore a self join). Or corletaed, 
or outer join, or unions, etc.
So bad deisgn.

My conculsion is that JDO is ok for small and simple but for large sites 
with lots of users, pass. A application designer, must spend some time 
matching business requirments, volumes, etc. to the physical design of 
the db).  Now if you have small DB with few users, JDO is OK.

Roll your own DAO works better (I do O/R with Java Beans (never EJB) 
sometimes contain other beans that have a rowset.) WIth Java Beans, I 
have a level of abstraction to the physical db (coded in Java and not 
XML).(Sample code at baseBeans.com based on Struts 1.1)

On the Sun home page for JDO it says "developers do not need to know 
SQL". Not all the developer need to know it, but someplace someone needs 
to know it.

Vic

Magesh Umasankar wrote:

> From: "Jakarta General Newsgroup" <@[EMAIL PROTECTED]>
> 
>>Note JDO are not scalable nd only simple. 
>>
> 
> I know this isn't the place to discuss this,
> but couldn't resist asking for the reasons
> supporting this assertion.
> 
> 
>>Vic
>>
>>
> 
> Cheers,
> Magesh
> 
> *********************************************
> *  Last night I played a blank tape at full *
> *  blast. The mime next door went nuts.     *
> *********************************************
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to