On Tuesday 28 January 2003 01:32, Hunsberger, Peter wrote: > >> if (exist <esql:more-results>) > >> LIMIT 5+1 > >> else > >> LIMIT 5 > >> > >> I think this is an elegant solution. What you think? > > > > Sure - but the problem is that we also would need to adjust the length > > of the resultset inside the helper class. (you always want to see only 5 > > rows in your page) > > > > The length of the resultset inside the class would sometimes be one more > > and sometimes *exact* - depending on whether there is a <more-results> > > tag or not. Which would be very confusing! > > > > Give me a day to think about this... > > Torsten, > > You're chasing a non-existent problem. There is never a real life case > that will have both good performance for N records and bad performance for > N+1 records. The only way you can guarantee having good performance for N > records is if you can build an index. If you can build an index then the > search will always terminate after looking at N+1 records.
I give you a "real world" case; In natural language; Give me the first COLOR (3D point) which resides not further than dE units from COLOR [L1, a1, b1]. In SQL database, I can only place the L, a, b columns, individually, and the spherical search would be; WHERE SQRT( SQ( L - L1 ) + SQ( a - a1) + SQ( a - a2 ) ) < dE where L1, a1, b1 and dE are parameters given at the invocation of the Select statement. <exclusion> I could go into a long discussion how this could be optimized, both in SQL (multi-levelled subqueries and regeneration of indexes) and internal to the DB engine (3D indecies), but I won't. </exclusion> If I have a well populated database, evenly and randomly spread out, I will on the average have a 100% penalty on LIMIT N+1, as the search will go through roughly the same number of records to find the "next one", which I don't care about. Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
