NYCPHP Meetup

[Joseph Annino]

I am working on a project with a similar problem of large result sets, and a
relatively slow query due to many table joins and fulltext indexes.  While I
don't expect the site to get huge traffic, queries take about a second or
two on my Dual 500MHz Apple G4, and this site will be hosted on a shared
server at an ISP, where I would think it would just get slower.

So I was thinking as a way of extending your idea of passing keys through a
URL redirect, I'll put the IDs from my result set into a session variable.
This poses two problems. First users need to get a cookie (or I need to go
through hoops) to store the session id.  Second, users may want to open
multiple windows with multiple searches, so there needs to be a way of
associating more than one search with a session.

I'm thinking a way to kill two birds with one stone is to create a unique
'search session id' and place it in hidden fields and urls of the pages that
are part of browsing a particular result.  A new ID is created whenever the
user hits the search button.

On 8/29/02 12:42 PM, "janis p gale" <sharpwit at hotmail.com> wrote:

>> But what if the query has multiple joins? It seems inefficient to re-run
> the
>> query each time. If I want to cache the original result in a new MySQL
>> table, then I have to manage that on a per-user basis. This implies using
>> cookies or session ID to track the user.
> 
> not sure, but a strategy i used to use in coldfusion/ms-sql (before you all
> gag, be happy to know i've migrated myself to learning php/mysql during this
> period of unemployment) involved performing the query, then redirecting the
> user to a view-results page which used an URL variable set by the
> query/redirect script containing the id's of the items in the result set.
> 
> so let's say the user searched for products - one script would perform the
> rather complex set of queries for the search, build an id list, redirect to
> an URL looking like /?id_list=0.2.5.7.8.9.24.78, and the results page would
> re-query the db for the product details based on a subset of the
> dot-delimited id_list.
> 
> said query would look something like:
> q = mysql_query("SELECT id, name, desc FROM product WHERE id IN (" .
> replace(".",",",HTTP_GET_VARS["id_list"])) . ")") or die("!mysql_query");
> 
> this Might seem problematic for large result sets, but actually you'd be
> surprised how much data you can stuff into an URL with no worries
> whatsoever.
> 
>