Search thoughts
in [General]
|
Prev: questions about using include() in php
Next: php help.
From: Richard Heyes on 19 Jul 2008 05:47 Hey, I was hoping to get some ideas on improving a sites search. Currently I have two - not a lot but I've been thinking about this for a few minutes. Currently the site in question uses a very basic LIKE in MySQL, eg %blah%, but naturally this finds terms such as hjkblahbjkk - which is not desired. Or such matches should be ranked lower than something that matches the exact word blah. My thoughts are using a points system, eg assigning 5 points for an exact word match, 1 for a partial match. And then ordering the search results by the total points assigned. Either that or using external search code and not worrying so much. Cheers. -- Richard Heyes
From: Richard Heyes on 19 Jul 2008 10:32 Mark Kelly wrote: > Hi. > > On Saturday 19 July 2008, Richard Heyes wrote: >> Currently the site in question uses a very basic LIKE in MySQL, eg >> %blah%, but naturally this finds terms such as hjkblahbjkk - which is >> not desired. Or such matches should be ranked lower than something that >> matches the exact word blah. > > I did this with 2 queries, and no need for messing with points etc (unless > you particularly want to). > > Start with "LIKE 'word'" query and pull the results into a results array. > Then do the same query but with "LIKE '%word%'" and loop through append > the results to the results array. Use something like "if > (!in_array($thisResult,$resultSet))" while appending to avoid duplicates. Well no. LIKE is slow and so is in_array(). Admittedly it's not a busy site, but still. How much traffic do you have and what's your hardware? Are your queries cached and subsequently repeated? Do you pre cache common queries? Cheers. -- Richard Heyes
From: tedd on 19 Jul 2008 10:44 At 10:47 AM +0100 7/19/08, Richard Heyes wrote: >Hey, > >I was hoping to get some ideas on improving a sites search. >Currently I have two - not a lot but I've been thinking about this >for a few minutes. That'll leave a mark. :-) >Currently the site in question uses a very basic LIKE in MySQL, eg >%blah%, but naturally this finds terms such as hjkblahbjkk - which >is not desired. Or such matches should be ranked lower than >something that matches the exact word blah. My thoughts are using a >points system, eg assigning 5 points for an exact word match, 1 for >a partial match. And then ordering the search results by the total >points assigned. I'm sure that would work, but just how many LIKE items do you want to show the user? For me, I would rather not show them anything if there is nothing on my site that matches their exact search criteria. The point being, from my perspective, users don't spend a lot of time reading results. They want answers quick and short. I would think that if you provided them with a long list of "Did you mean this?" results -- that might frustrate the user. If I did that, then I would also highlight each LIKE search word to show the user why the LIKE results were being presented to them. >Either that or using external search code and not worrying so much. Considering all, using an external search would probably be better -- less time worrying about it and delivering good results to users queries is not as simple as it seems. However, if someone could come up with a better way, I am sure you could. But, the point is, would it make a difference? Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com
From: Richard Heyes on 19 Jul 2008 11:11 > I'm sure that would work, but just how many LIKE items do you want to > show the user? For me, I would rather not show them anything if there is > nothing on my site that matches their exact search criteria. Certainly an idea, but something like "We also found..." might be helpful in regard to typos. > The point being, from my perspective, users don't spend a lot of time > reading results. They want answers quick and short. I would think that > if you provided them with a long list of "Did you mean this?" results -- > that might frustrate the user. A good point. For example I rarely go further than the first page on Google (I never need to really, but whatever...). > if someone could come up with a > better way, I am sure you could. Thanks for the vote of confidence, but I've kept away from search as it doesn't overly interest me. In fact that's quite an over statement. It really bores the pants off me. > But, the point is, would it make a > difference? Well spending some time on it will improve it as it's just the basic LIKE at the moment, but point taken - I really don't want to spend a lot of time on it. -- Richard Heyes
From: Mark Kelly on 19 Jul 2008 13:42
Hi. Just noticed I replied direct rather than to the list last time, sorry about that. On Saturday 19 July 2008, Richard Heyes wrote: > How much traffic do you have and what's your hardware? Are your queries > cached and subsequently repeated? Do you pre cache common queries? I've done this kind of search twice, but both were for internal web apps so I can't link you to them. In both cases I return only items IDs and limit it to 10 results, with the subsequent queries being done only if the previous ones didn't return enough results to fill the page. Both of these speed it up a lot, obviously. One of them has a possible max of 6 different ways to examine the data tables, and still return a full results page in under half a second. Nothing is pre-cached, and I'm really not sure about the hardware, sorry, that's the IT guy's problem. I don't imagine it's anything spectacular though. The apps get quite heavy use but I'm with Tedd on the results issue, we only see maybe 10% of the users going to page 2, but these are internal users searching company data, so the pattern may not be typical. Hope you find something you're happy with, Mark |