> > No, you do a single select that returns 100 results...
>
> Does a single select mean a fast select ?
Provably always? Perhaps not.
But requesting data via a single select statement returning 100 rows
means that you only have to submit the request once, and it means that
the result set only has to be set up once, which is quite likely to save
some work.
If you're going to read 100 lines of data from a file, would it make
more sense to:
a) Open the file 100 times, fseek() to the right spot, and then close the file, or
b) Open the file once, and do 100 fseek() calls?
If you're just opening a file, there's not a huge amount of overhead
associated with that. Setting up a DBMS query is quite a bit more
costly, so that the effort looks like:
a) Open a session connection, submit a query for one record, and process it, then close the connection, and do this
100times, versus
b) Open a session connection, submit a query returning 100 records, and process them all.
The overhead surrounding submitting and processing the query is quite a
bit more than that involved in opening/closing files, so cutting down on
it should be pretty worthwhile...
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://cbbrowne.com/info/nonrdbms.html
"When we understand knowledge-based systems, it will be as before
-- except our fingertips will have been singed." -- Alan Perlis
