> But joins are what relation databases excel at, so PHP would be the > bottleneck in your example.
Not always... If your JOIN can not be easily constrained in the query, until some kind of processing of the result set takes place, you can end up with a monster interim result set that will swap the DB server, and send it to its knees. For example, if you need a result set of 10 items, some of which (but not all) relate to a second table, and the left outer join the generates millions of rows... Also: SQL is great at many things. But something like a tree traversal or other results that depend on the rows returned can be a real bear, especially for pages that are not your core scalable must-have part of the site -- Where you don't want to complicate everything else for just this one admin/report page. I'm only saying that, on occasion, the dozen DB calls wins out over a JOIN that swaps madly. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
