Subject: Re: Open Source JDO Implementation?? From: Vic Cekvenich <[EMAIL PROTECTED]> === View do not offer any performance benefits in any DB.
If there is interest in a non-JDO or O/R mapping dataccess layer, I could write up/or document my "low-tech" approache which uses JDBC/RowSets and Generic Update. Key feature is that retreivals are ANY SQL string that the DB understands. The code is at baseBeans.com downloads (in the Struts example) but.... like a white paper. Andrus Adamchik wrote: > > Jakarta General Newsgroup (@Basebeans.com) wrote: > >> 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". > > > > If it comes to this level (optimizing joins for the target db by hand), > you are better off writing a database view or a stored procedure, and > still preserve object abstraction in your java code. This would allow > painless migration between the databases (for Java developers that is, > for database people it is always > painful) , as well as make life > easier for the next guy coming in after you left the project. > >> On the design side, you can't model certain things like employes and >> managers. > > (Manager is an employee, therfore a self join). > > > I didn't know JDO was so limited. Any O/R framework that has > relationships would allow that. > > > 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). > > > Yes, programming in XML is bad, but still having it as a glue between > the parts is unavoidable these days :-). > > >> 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. > > > That is so true. If you don't provide a way around your object layer (or > rather find a sinergy between O/R layer and raw SQL execution) then the > O/R it is pretty much useless. > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
