We have cached queries that hold information that is used on every page hit
of the site. Every page returns a random record from the cached record set.
Now, each of these records have links to products, and each record has
several products associated with it. Ordinarily, the first link is
displayed. However, in one section of the site, all of the products are
displayed (sometimes these are recipe ingredients so let's assume that's
the case). Below the section that lists the products is a section that has
links to all recipes that contain that product.
Now then (what does that phrase mean anyway?), I have cached queries that
contain the recipes and the associated products but the query is run on the
recipe id. However, to get the list of all recipes that contain a specified
product, I'd have to use a significantly different query but one that
contains all of the same fields, joined in a similar way. The only thing
that changes is the search criteria: you are either searching by recipe id
or you are searching by product id. In both cases, a lot of the same
information is returned.
Right now, this sucks.
However, if I could load in a query of all recipe ids joined on the product
ids and another list of the copy for the recipes joined on their recipe id
(including the first product id), I could do this instead:
1) display the copy linked to the recipe id where that needs to happen
(every page of the site) by outputting a random record from the copy/recipe
id set
2) generate the list of ingredients by querying the recipe id/product id
list for that recipe id
3) generate the list of recipes by querying the recipe id/product id list
for the product id
That means that instead of caching 100 recipe id/product id queries plus
500 product id/recipe id queries (or hitting the db every time or loading
the records into a structure), I could cache 2 queries and query them as
appropriate. It would be much simpler and would save resources lost to all
other methods.
Ding ding ding!
At 03:09 PM 2/1/01 -0800, you wrote:
>I haven't thought of a kickass problem/solution that would need query a
>query ability so I'm happy that's it is there to use but not, stoked, at
>least not yet. =)
>
>Have not tested or even had the priv to touch 5.0 yet but isn't just query a
>query just a search option? So we can do a search for array values, structs,
>and now arrays which are in a way structs. Hmm..actually, I have yet to use
>structfind() with queries so I wouldn't know if that works already.
>
>Maybe with query a query you can isolate a range of records that fits a new
>condition on a existing query? but wouldn't that be a waste of ram and sql
>power to return a large query in the first place that you need to do sub
>queries on?
>
>Basically, I'm trying to find a good problem that would really need the
>feature and would speed up the performance while not wasting resources.
>
>Xing
>
>
> > So who's stoked about the Query a Query ability? Pretty damn cool eh?
> >
> > Michael Buffington
> > [EMAIL PROTECTED]
> > (714) 556-3890 x222
> > http://www.price.com
>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
