On Mon, Nov 10, 2008 at 9:47 AM, <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. I'm not saying such situations don't exist, but in my experience they are pretty rare -- especially since MySQL added support for subselects. Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
