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
