Re: Searching on AlphaNumeric Content Only

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- Original Message ----
> From: "sono-io@xxxxxxxxxxxxx" <sono-io@xxxxxxxxxxxxx>
> To: PHP General List <php-general@xxxxxxxxxxxxx>
> Sent: Thursday, September 3, 2009 12:12:40 PM
> Subject: Re:  Searching on AlphaNumeric Content Only
> 
>     Thanks to everyone who has responded.  After reading everyone's response, I 
> think I have a very simple way to solve my "problem".
> 
>     Using my original example, if someone wants to find item # 4D-2448-7PS, no 
> matter what they type in, I'll take the input, strip out all non-alphanumeric 
> characters to make it 4D24487PS, add the wildcard character between each of the 
> remaining characters like so, 4*D*2*4*4*8*7*P*S, and then do the search.

The correct wildcard syntax to work in any DB (Oracle, MySQL, MSSQL, etc), is % and not * if I remember correctly.  Searching like this is ok but won't be efficient when you have a lot of rows.  As for external file processing txt, csv, etc... I recommend you create a separate mechanism for it since each storage medium is meant for different purposes.  txt (both delimited and fix formatted) and csv are usually meant for importing/exporting between various RDBMS types and different companies.  They're not mean for fast searching of data.  I suggest you think about the amount of the data you have to deal with 1st and how often will the search be done on that data.  It's probably easier and faster just to import the ascii into db and do you search on db if you have to work with any ascii.

As for adding another field to the db, perhaps your project just started?  If so, wouldn't it be better to do it with the future in mind so later you won't have to go back and redesign the db and modify the codes because now you have over 100k rows to search and the search occurs just about every other hits?  That time you now have could be used for code optimizing for better performance, add more features/functionalities to the site, etc... :)  Trust me, searching the db table with over 200k rows and return the results with multi-table joins based 1 criteria isn't fun.  Keep in mind that you shouldn't keep the users waiting more than 5 seconds.  Only exception to that rule is data mining where you'll have millions of rows to work with ;)  Then it's no longer your problem.  It's the DBA :D

Regards,
Tommy

> 
>     Still being new at this, it seems to be the simplest approach, or is my 
> thinking flawed?  This also keeps me from having to add another field in the db 
> to search on.
> 
>     BTW, this solution needs to work with any db, even ASCII files, so it has to 
> happen in PHP.
> 
> Thanks again,
> Frank
> 
> --PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux