Dan Shirah schreef:
Hello, I'm hoping to get a few good ideas on the best way to perform a search of PHP results. Currently I have a page that returns a list of collapsed customer data: Example + John Smith + Jane Doe + Robert Jones + Dale Bennett If the user clicks on a customer name it will expand the selection: Example - John Smith - 123 Anywhere Street - myCity - myState - myZipcode - myWebsite + Jane Doe + Robert Jones + Dale Bennett Now, what my client wants is a Search functionality that will allow him to type in myState and have the application automatically expand and focus on the first match. Then, be able to click "Next" and have it collapse the first result and expand the next result that contains the same state. Any ideas? I was thinking that maybe I would have to create a temp table so it could be searched against, but I'm not sure if that is the best idea. Also, in order to save processing time, the way I made the above expanding/collapsing list is I don't not pull in the customer details intially but instead run a query and get the details when the name is clicked for expansion. This is because there could be potentially 1,000's of result and getting all of the names and all of the details at page load would 1) take longer than a user is willing to wait 2) exceed the timeout 3) exceed the memory allocation
I would think about caching data to streamline searching ... it would be very helpful if your address data was normalized when possible (e.g. states are related to users based on a database id rather than being loose bits of text) .. so that you can precalculate (e.g. via a cronjob) user ids that 'match' against certain strings) ... where you stick your cache is upto you. I would also cache the structured data for each user so that you can very quickly output (e.g. via JSON) the data for a given user/users to the browser. And then the fun part: build an ajaxy wotsit that paginates, sorts, searches and highlights the data ... and then couple it to server scripts that use the precalculated data to cough up matching users id (for searches) and userdata (for display). most of the hardwork will be in building the client side magic, the scripts that act as an interface on the precalculated data will be simple, and the precalculation routines shouldn't be to hairy (although you'll have to think careful about how to cover all your angles when it comes to the kind of data that can be search through)
Thanks for any help/ideas.
I'm interested to know if my brainfart made any sense to you :-) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
