in reply to More on selecting rows with DBI...

I would guess that DBI would process all 50000 records reguardless of what you do with the data. I am not posivite about that though. The safest bet for database performance is to always try to increase your query performance. (i.e. if you only need 20 rows, then only retrieve 20 rows). That way DBI will not have to do all the extraneous processing.

In sybase there is a command "set rowcount NUMBER" which will only retrieve the first NUMBER rows. There may be something similar for the database you are using.

So if you know you are only going to use the first 20 rows of a 50000 row dataset, then you might be able to limit it in your query:
my $sql =<<EOF; set rowcount 20 SELECT * from total_huge_table EOF my $sth = $dbh->prepare($sql); $sth->execute(); ... more code here ...
If this kind of query restriction is available via a perl module, I would guess that it would be mentioned in the individual DBD module perldoc pages. I dont think this could be a DBI feature since it is probably really database dependent.

I just noticed that Mysql has a way to limit in the SQL also: SELECT * from huge_table LIMIT 1, 20This will return the 1st through 20th rows. (untested, but that is what the O'Reilly mysql book says: MySQL & mSQL by Yarger, Reese, & King)

Well I dont think I answered you exactly, but maybe some of this will help.

Replies are listed 'Best First'.
RE: Re: More on selecting rows with DBI...
by BBQ (Curate) on May 02, 2000 at 09:40 UTC
    Actually, I'm sorta new to MySQL...

    I've used Oracle for the past years and there are a number of ways that this can be implemented on the database side (alot harder than LIMIT, BTW) by using PL/SQL. Now that I've been forced to use other DBMSs (MySQL being one of them), I'm trying to cut down to the least common denominator of SQL in order to maintain a certain degree of portability between the systems.

    DBI has been great as far as portability, but I have found that my Oracle vices have prooven to be rather disappointing at times, since DBD::Oracle allows you to do fancy Oracle proprietary stuff (like selects within selects for instance)...

    Oh, if only the DBMS vendors could agree on ONE PLAIN FLAVOR OF SQL it would make my life sooo much easier...
      Oh, if only the DBMS vendors could agree on ONE PLAIN FLAVOR OF SQL it would make my life sooo much easier...

      I think this will happen about the same time Microsoft voluntarily open sources and GPLs Windows along with porting Office to Linux.

      It is too bad though. Standard SQL would make life a lot easier for us all.

      In the mean time maybe you can keep all the database specific code in one module, and dynamically require that library depending on which DBD you are using. So that way you should really be able to utilize the power of each database, but still maintain a some-what portable app. Then you can create a database module for each database the app will be using.