I’m writing a php-mysql application. The application allows the user to run a search against the database. When the search is run, if the user clicks on the back button to go back to it after examining an item brought up by it, they are asked if they would like to resend the query (it uses post). Which would rerun the search in the database. Using get wouldn’t result in the request to repost – but it would still run the search again.
Is there a way to store the search and recall it, with out rerunning it in the database?
This can be saving it in the database, or somehow in the php – maybe with sessions? There can be a lot of data coming out of these searches, I feel like it’s probably too much for sessions.
The other way I can imagine is to store it in the database, in a temporary table of some kind. Creating the table with the columns I intend to query, then selecting into an insert. Then selecting * from the table. This also seems rather like a bad idea. Lots of dynamically created temporary tables floating around.
I know this can be done. Saved searches are things you see in many web applications. So how is it generally done?
memcached
or
APC
However, I notice that you’re not giving any reason why you want to cache the results of a search. “Because it’s faster, and I read that it makes my app more scalable,” is the usual reason for this. This smells like premature optimization.
I recommend you build your application and profile it. How costly are these “searches”? Why are they costly? Is it poor schema design? Is it poor indexing? Is it poor choice of storage engine?
You do realize that MySQL has a query cache, right? In many cases this may be all you need. Try running one of your expensive “search” queries using the mysql client and note the time, then run it again. See?