On Mon, Nov 10, 2008 at 9:47 AM, <[EMAIL PROTECTED]> 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
