ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michal Malecki" <misie...@poczta.onet.pl>
Subject Re: R: What is N+1
Date Wed, 09 Feb 2005 15:27:57 GMT
I wonder one thing, which Abdullah and I have already mentioned - what if
parent is big and has a lot of children. We are getting through the net n
times parent record. The most efficient would be, I think, to make 2
selects - one for the parent records, and one for all of the children, plus
the parent pk. But I'm afraid it would look ugly in the configuration.
Anyway, maybe we can invent something that would be both readable and
efficient?
Michal Malecki

> Vic,
>
> I'm not sure what you're point was, but N+1 selects is THE most common
> relational databases performance problem caused by application
> developers today.
>
> Understanding it is critical if you want to avoid making this mistake.
>  Not every application will have the luxury of simply being 1:1
> Table:Screen.  In fact, I've almost never seen this to be the case in
> enterprise applications.
>
> Consider a 3 tier hierarchy like in JPetStore:  Categories -1---M-
> Products -1----M- Items.
>
> For illustration purposes, the number of queries to load this data
> with an immediate or lazy load strategy is:
>
> 1 * count(categories) * count(Products)
>
> So if we have 5 categories and 25 products (a relatively small data
set)...
>     ...you'll generate 125 hits against your database.
>
> Now consider 25 categories and 125 products (still a very small data set),
>     ...you'll generate 3125 hits against your database!!!
>
> You can see how this could pose a HUGE issue, even with only a small
> amount of data.
>
> With the N+1 selects solution, you can do this with one query, with
> one hit to the database -- no matter how many relationships you have
> or how much data.
>
> Trust me bud, this is VERY good advice.
>
> Cheers,
> Clinton
>
>
> On Wed, 09 Feb 2005 08:36:44 -0600, friendVU admin
> <maillist@friendvu.com> wrote:
> > I see.
> > I am not sure if that is good advice. I think if you click on a table
> > you get the detail, that makes sense.
> > Else... row processing is not for SQL, SQL is based on relational
> > algebra and Set Theory and Venn diagrams, ie... you work on a set of
> > records, not cursor processing.
> > I am sure some may find limited use for it.... IMO, it's something to
> > avoid.
> >
> > .V
> >
> > Fabrizio Gianneschi wrote:
> >
> > >The reason is explained well in the SQLMaps documentation:
> > >
> > >
> >
> >



Mime
View raw message