I must admit I don't do this specifically, but the approach I take from
getting my results from Swish-E might be of help.....
The first step I do is to index my database using a custom program, this
program basically generates a swish-e formatted record for every product
and brand in our database. The index numbers are also provided (as a
property from memory, e.g. <id>5</id>).
Of course when I index I include this in my PropertyNames and MetaNames
config. (not 100% sure which one is needed, I think Propertynames, but
it works for me in both)
I do a swish search as per normal, except I format the results back at
me with the index of the record that matches....
$main_swish_cmd = getConfig("search_swish_path") . " -w \"$search_term\"
I have different types (the match could be a product, so I want to
display a pretty picture and price etc, or it could be a category, which
just needs a description, or perhaps a brand, which needs the brands
logo and a short blurb, etc) . From the swish results I can now
determine how to display each result, as well as any other properties i
<this bit is where it might get interesting for you>
I usually follow this up with sql query to get the display correct. I
find with 10 results per page, 10 sql queries isn't too bad so I just
loop through the results and do an sql query on each. I would probably
recommend looping through every query and build a list of id's and then
throw one query at the database
..... untested php code .......
$id = array();
foreach ($query as $q)
$id = $q->id;
$sql_categories = "SELECT count(*) as cat_count, c.name FROM products p
INNER JOIN categories c WHERE id IN " . explode(",", $id) . "GROUP BY
Of course this would be harder for your price points, but perhaps you
would need several queries, one for each price point. (and this would be
more efficient if the results were cached anyway)
My two cents :)
When i do
FranÃ§ois Tissandier wrote:
>> Yes. But, your example above shows small numbers per category. So
>> maybe you can just limit your search results and count them up --
>> might not be that slow.
> But the idea is to use those filters when you have too many results. If
> you have 5 results, no need to have this kind of info. Example just to
> make sure my frenglish is clear:
> the user is looking for a mouse, and just type "logitech". He sees 245
> results, that's a long list. But then on the left, he can see that there
> are 23 keyboards, 45 mouses, 34 speakers, etc... He clicks on "mouses",
> the search is launched again with a filter on the category metaname.
> Then again, if too many results, he can maybe click on the "optical"
> filter, and the search is launched again with two filters on two
>> Swish isn't a database, so you might also consider looking at your
>> results then using a database to pull in the categories like above.
>> A database is designed doing those kinds of queries.
> Yes I agree, it's very easy to pull those info from a db, but a db sucks
> when it comes to search! :) I don't display those info BEFORE searching,
> I display them for a specific search to help people refining. I'm sorry
> for not being clear enough. A database cannot do this, or with crap
> search possibilities.
> Is it possible with swish to just output the properties of my choice?
> That would make this faster. Like for instance asking for "category" and
> mouse logitech
> mouse logitech
> mouse microsoft
> keyboard logitech
> keyboard microsoft
> keyboard logitech
> No URL, no title, no ranking, just the data I need. I still need to
> process this output to count, but that's better than nothing I guess!
> Searches are already very fast, most of them running in 0.2 seconds on
> an index including almost a million words... So I can maybe spend a
> couple of seconds to process this.
> But I think that could be a killing feature for swish-e 3.0... Maybe i'm
> the only one looking for this?
> FranÃ§ois Tissandier
> IS Manager
> Tel: +33 1 30 46 39 23
> Fax: +33 1 30 46 39 11
> www.tebu-bio.com: the smarter way to buy research products
> P Think about the environment before printing this email / Pensez Ã
> l'environnement avant d'imprimer cet e-mail
> Users mailing list
Users mailing list
Received on Wed Jul 2 18:39:49 2008