From: Ben Dunlap on 3 Sep 2009 17:05 > > stripping, stemming, spelling corrections ? > ... uhm, that's probably why they invented regular expressions, isn't it? > > As I said, at the end of the day, this will be a manual slow, potentially wrong implementation of what we already have and use on daily basis. If you've got a regular-expression-based method in mind that simply nails the OP's problem, please share. I'm still not seeing how "regular expressions" is a sufficient answer to the OP's problem, which is basically fuzzy search. My sense is that regular expressions are for situations where you basically know just what you're searching for, but don't really know where it falls in your search space. The OP, on the other hand, is building a system where he won't know just what he's searching for -- all he'll know is that his search key is "sort of like" the thing he actually needs to find. You might be able to squeeze this problem, or at least some part of it, into a regex-based solution, but I don't think it's a natural fit. Ben
From: Lupus Michaelis on 4 Sep 2009 11:00 Ashley Sheridan a �crit : > What's wrong with using the wildcards that are built into most SQL > variants? Performance issues. Like is an operator to avoid when possible. -- Micka�l Wolff aka Lupus Michaelis http://lupusmic.org
From: Ashley Sheridan on 4 Sep 2009 11:02 On Fri, 2009-09-04 at 17:00 +0200, Lupus Michaelis wrote: > Ashley Sheridan a écrit : > > What's wrong with using the wildcards that are built into most SQL > > variants? > > Performance issues. Like is an operator to avoid when possible. > > -- > Mickaël Wolff aka Lupus Michaelis > http://lupusmic.org > You'll have far greater performance issues if you retrieve all those records and attempt to do the same thing inside of PHP... Thanks, Ash http://www.ashleysheridan.co.uk
From: Lupus Michaelis on 4 Sep 2009 11:06 sono-io(a)fannullone.us a �crit : > Here's an example: let's say there is an itemID of 4D-2448-7PS but > someone omits the dashes and searches on 4D24487PS. Is it possible in > PHP to have the find be successful, even if the search criteria doesn't > exactly match what's stored in the field? I think you don't follow the good path. A good way could be to have a strenger UI management. For exemple, here, you have an ID that is composed about 3 bits. So do the UI present three input fields, or write a smart input (with JS). Of course, in the control side (PHP), you have to check the format of the returned data. Here you can reject the input, or fall through some segment of code that try to interpret the submitted value. But in first time, do it simple and be rough to users. Usability can be improved in a second time. -- Micka�l Wolff aka Lupus Michaelis http://lupusmic.org
From: Lupus Michaelis on 4 Sep 2009 12:02
Ashley Sheridan a écrit : > You'll have far greater performance issues if you retrieve all those > records and attempt to do the same thing inside of PHP... It's why I speak about « avoiding » and not « bannishing ». Like can be usefull, I used to use it. But it is not the a good answer to all problems. The problem with like operator is it can't use the index (or in a very limited way). So I try to warn about it. So said, I never submit an all-retrieving method. I know it isn't the solution too. -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org |