[ic] Improve speed on retrieving data

[Peter Jakl]

Jon, I think you forgot the attachments. It sounds like this is exactly
what I need. I don't believe there's a way to optimize the query. We
need the ability to do general keyword searches such as "color laser
printer", etc. I created a single field that has the complete list of
keywords for each sku. I then do a "select sku from products where kw
like '%color%' and kw like '%laser%' and kw like '%printer%'". If there
is a better way within the scope of mysql, I'd like to know about it.

Peter


> -----Original Message-----
> From: interchange-users-admin@interchange.redhat.com
[mailto:interchange-
> users-admin@interchange.redhat.com] On Behalf Of Jon Jensen
> Sent: Friday, January 11, 2002 2:57 PM
> To: interchange-users@interchange.redhat.com
> Subject: Re: [ic] Improve speed on retrieving data
> 
> On Fri, 11 Jan 2002, Peter Jakl wrote:
> 
> > I basically have the following:
> >
> > [query st=db list=1 more=1 ml=20 sql='select sku from products where
> > ...']
> >
> > The select is doing a sloooow keyword search on a database with
179,000
> > products. I'm using mysql. I have a much faster method of generating
the
> > list of skus, but need to run an external command.
> >
> > Is there some way to run this command to generate the list of skus,
> > while preserving the "more" and "list" feature?
> 
> You could call your external command in a usertag, then return the
list.
> I've been meaning to write some docs on this for a while, so I sat
down
> and did a usertag that will return either an inline text list or a
Perl
> array reference, and a tutorial HTML page that shows it in action (see
> attachments).
> 
> Just customize the usertag to call your external program, and you
should
> be up and running. Note that you will have to make your usertag global
to
> call an external program. (Put it in interchange.cfg or in the usertag
> directory in the Interchange root directory.) Otherwise, this usertag
runs
> fine as a catalog usertag.
> 
> Note that others' suggestions to optimize your query, etc. are still
valid
> and may be the best way to go. But this shows that the way you thought
of
> is possible. Let me know how it works for you.
> 
> Jon