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
<[EMAIL PROTECTED]> 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:
> >
> >
>
>
