For now, probably more effective to run separate queries, in 4.1 mySQL
is supposed to include stored proc's at least for InnoDB tables, which
would be best of all... and is what I would like to see, in addition to
multiple query/recordset returns...
in MS-SQL/DB2/Oracle, i've created some complex security models, that
return all the security parameters for a given user in one stored
procedure, that returns 4 recordsets...
If there is no easy way to return the data you want, do it in code,
this may have a higher memory hit, but will be more maintainable in
code... try to break it into smaller functions if you need to, then
you can have the functions call a stored procedure later when that
functionality becomes available.
Michael J. Ryan - tracker1[*at*]theroughnecks.com
Roughneck BBS: http://www.theroughnecks.net telnet://theroughnecks.net
Y!: aztracker1 - aim: azTracker1 - icq: 4935386 - msn: see email
One program for aim/icq/yahoo/msn/irc - http://www.trillian.cc/
"Matthew Nock" <[EMAIL PROTECTED]> wrote in message...
> Is it more efficient to run a SELECT query on a MySQL database that
> retrieves maybe 100 records from approximately 6 tables (based on one
> result - such as a product ID) and then process these results using PHP....
> or is it more efficient to run say 6 SELECT statements that get the exact
> details we want, and in the process returning a smaller number of results
> over all?
> If its the first of the two, then is it possible to use the MySQL "Group by"
> structure to group the results, and store the results of each "group" (for
> example a product category) in separate arrays?
> ie; array_prodcat1, array_prodcat2 etc etc?
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php