Searching on AlphaNumeric Content Only
in [General]
|
From: Eddie Drapkin on 4 Sep 2009 16:22 On Fri, Sep 4, 2009 at 12:02 PM, Lupus Michaelis<mickael+php(a)lupusmic.org> wrote: > 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 > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > So far, in this thread, there've been a few solutions: 1) LIKE in SQL. 2) REGEXP in SQL. 3) PCRE in PHP 4) Other fetch all methods in PHP. The one thing that I'm seeing as a consistent agreement is that the performance hit of whichever of the aforementioned measures is going to be enough to be considering something else. I briefly mentioned - I apologize for the brevity of that email because I was in a hurry - that a legitimate full text search engine is the right solution to this problem. The only problem with deploying a full text search engine is going to be the difficulty in the deployment and perhaps issues if you're on shared hosting (but then again I am of the opinion that those who choose to run with shared hosting dig their own graves in more ways than one). What a full text search engine gives you is flexibility in your searches, such that the initial question, when I read it, I thought "Oh, someone will tell him to use Sphinx or Solr as both have special filters for word seperation and would handle this without any special instruction." Instead, this is never even brought up! Why was using a full text search engine to do this sort of thing - not to mention the other benefits that it would bring (responsiveness and flexibility in searching, speed, decreased use of MySQL, etc. etc.) - rejected so offhandedly? I can't actually think of a better way to do this without requiring a whole heap of overhead, either processing or programming.
From: Robert Cummings on 4 Sep 2009 16:36 Eddie Drapkin wrote: > On Fri, Sep 4, 2009 at 12:02 PM, Lupus > Michaelis<mickael+php(a)lupusmic.org> wrote: >> 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 >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > So far, in this thread, there've been a few solutions: > 1) LIKE in SQL. > 2) REGEXP in SQL. > 3) PCRE in PHP > 4) Other fetch all methods in PHP. > > The one thing that I'm seeing as a consistent agreement is that the > performance hit of whichever of the aforementioned measures is going > to be enough to be considering something else. I briefly mentioned - > I apologize for the brevity of that email because I was in a hurry - > that a legitimate full text search engine is the right solution to > this problem. The only problem with deploying a full text search > engine is going to be the difficulty in the deployment and perhaps > issues if you're on shared hosting (but then again I am of the opinion > that those who choose to run with shared hosting dig their own graves > in more ways than one). > > What a full text search engine gives you is flexibility in your > searches, such that the initial question, when I read it, I thought > "Oh, someone will tell him to use Sphinx or Solr as both have special > filters for word seperation and would handle this without any special > instruction." Instead, this is never even brought up! > > Why was using a full text search engine to do this sort of thing - not > to mention the other benefits that it would bring (responsiveness and > flexibility in searching, speed, decreased use of MySQL, etc. etc.) - > rejected so offhandedly? I can't actually think of a better way to do > this without requiring a whole heap of overhead, either processing or > programming. I've just sort of stopped in on this thread... but why isn't MySQL's FULLTEXT engine being considered? Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
From: Tommy Pham on 4 Sep 2009 18:11 ----- Original Message ---- > From: Robert Cummings <robert(a)interjinn.com> > To: Eddie Drapkin <oorza2k5(a)gmail.com> > Cc: Lupus Michaelis <mickael+php(a)lupusmic.org>; php-general(a)lists.php.net > Sent: Friday, September 4, 2009 1:36:08 PM > Subject: Re: [PHP] Searching on AlphaNumeric Content Only > > Eddie Drapkin wrote: > > On Fri, Sep 4, 2009 at 12:02 PM, Lupus > > Michaeliswrote: > >> 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 > >> > >> -- > >> PHP General Mailing List (http://www.php.net/) > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > > > > So far, in this thread, there've been a few solutions: > > 1) LIKE in SQL. > > 2) REGEXP in SQL. > > 3) PCRE in PHP > > 4) Other fetch all methods in PHP. > > > > The one thing that I'm seeing as a consistent agreement is that the > > performance hit of whichever of the aforementioned measures is going > > to be enough to be considering something else. I briefly mentioned - > > I apologize for the brevity of that email because I was in a hurry - > > that a legitimate full text search engine is the right solution to > > this problem. The only problem with deploying a full text search > > engine is going to be the difficulty in the deployment and perhaps > > issues if you're on shared hosting (but then again I am of the opinion > > that those who choose to run with shared hosting dig their own graves > > in more ways than one). > > > > What a full text search engine gives you is flexibility in your > > searches, such that the initial question, when I read it, I thought > > "Oh, someone will tell him to use Sphinx or Solr as both have special > > filters for word seperation and would handle this without any special > > instruction." Instead, this is never even brought up! > > > > Why was using a full text search engine to do this sort of thing - not > > to mention the other benefits that it would bring (responsiveness and > > flexibility in searching, speed, decreased use of MySQL, etc. etc.) - > > rejected so offhandedly? I can't actually think of a better way to do > > this without requiring a whole heap of overhead, either processing or > > programming. > > I've just sort of stopped in on this thread... but why isn't MySQL's > FULLTEXT engine being considered? If I remember correctly, it's only on available on MyISAM table type. I don't think the OP mentioned that he's using MyISAM or MySQL for that matter. > > Cheers, > Rob. > -- > http://www.interjinn.com > Application and Templating Framework for PHP > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php
From: Paul M Foster on 4 Sep 2009 18:14 On Fri, Sep 04, 2009 at 04:22:18PM -0400, Eddie Drapkin wrote: > On Fri, Sep 4, 2009 at 12:02 PM, Lupus > Michaelis<mickael+php(a)lupusmic.org> wrote: > if you're on shared hosting (but then again I am of the opinion > that those who choose to run with shared hosting dig their own graves > in more ways than one). Any time you or someone else would like to backstop me in setting up a dedicated server on rackspace or somewhere else, for free or really cheap, you let me know! Otherwise, those of us with less than complete expertise in server setup are stuck with shared hosting. ;-} Paul -- Paul M. Foster
From: Robert Cummings on 4 Sep 2009 20:15
Paul M Foster wrote: > On Fri, Sep 04, 2009 at 04:22:18PM -0400, Eddie Drapkin wrote: > >> On Fri, Sep 4, 2009 at 12:02 PM, Lupus >> Michaelis<mickael+php(a)lupusmic.org> wrote: > >> if you're on shared hosting (but then again I am of the opinion >> that those who choose to run with shared hosting dig their own graves >> in more ways than one). > > Any time you or someone else would like to backstop me in setting up a > dedicated server on rackspace or somewhere else, for free or really > cheap, you let me know! Otherwise, those of us with less than complete > expertise in server setup are stuck with shared hosting. ;-} For a few hundred bucks a year you can get a VPS (Virtual Private Server), which gives you root access. once you get a couple of clients on it, it will pay for itself year after year. If you have clients that don't use much resources, you can put a few on and even make a profit on the hosting alone. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP |