Re: object persistence within a session
| From: | Ashley Sheridan | Date: | Mon, 10 Nov 2008 14:53:47 +0000 |
| Subject: | Re: object persistence within a session | ||
| References: | 1 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-283181@lists.php.net to get a copy of this message | ||
On Mon, 2008-11-10 at 14:47 +0000, ceo@l-i-e.com 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