On Mon, 2008-11-10 at 14:47 +0000, ceo@xxxxxxxxx wrote: > > 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. > > > Then surely it is still a badly created query? If you're using PHP to filter the results, even if it's in order to create a second query, your SQL is not as good as it could be. The only thing that would benefit is where a query needs information that is only available from outside the database, which in turn is based on information from a query. Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
