I'm not aware of any such optimization... I do know that depending on the driver and database that you use, it's generally one of three things that kills performance:
1) Connection, or transaction initiation (with Oracle this is a big deal) 2) The actual JOIN itself (mostly a DB design issue, outer join performance etc.) 3) ResultSet iteration and data retrieval (lots of factors here, width, network, disk I/O etc) Generally, N+1 solutions work well where #2 is not an issue, but #1 and #3 are. This is more often the case because "most" databases are designed with JOIN performance in mind. Otherwise, multiple requests via lazy or immediate loading works if you have (#1 & 3) superfast I/O, a good driver, pooled connections, and a simple application design that is basically 1:1 table:screen. I'll admit (for Vic), I've worked with databases so bad that I've done in-memory joins of JavaBeans after retrieving table data separately. I even have a neat little BeanJoin utility that does joins on JavaBeans using their properies! Cheers, Clinton On Wed, 09 Feb 2005 18:16:33 +0200, Abdullah Kauchali <[EMAIL PROTECTED]> wrote: > > >Clinton wrote: N+1 selects the other way around is a 1:1 or an M:1 > >relationship > >(child has ref to parent), which iBATIS has always supported through > >nested property mappings in the resultMap...for example: > > > ><result property "product.id" column"PRODUCT_ID" /> > ><result property "product.name" column"PRODUCT_NAME" /> > > > >Doing the mapping in code is fine, it's just more work for you. It > >gets a lot harder when you have 2 or 3 relationships....which iBATIS > >supports out of the box. > > > > > > > Yes! :) Can I ask another question regarding simple joins: do you > have any knowledge > of JDBC drivers doing some sort of optimisations to avoid duplicating > the parent > table's records. (In an earlier post we spoke about the increase in > payload size and was > wondering if JDBC itself handled the "normalised" (if-u-will) resultset > in transit?) > > >Overall, each application will have different needs. Some will work > >best with immediate load (multiple queries, same connection), otherw > >will work best with lazy load (multiple queries, different > >connection), and others still will require the N+1 selects solution > >(single query, single connection). > > > >I just wanted to make sure nobody was painting all solutions with the > >same brush.... ;-) > > > > > For sure! > >
