On Thu, Jan 28, 2010 at 10:49:17AM -0500, Robert Cummings wrote: > Paul M Foster wrote: >> On Thu, Jan 28, 2010 at 01:31:30AM -0800, Allen McCabe wrote: >> >> <snip> >> >>> SIDE QUESTION: What do you think of my use of serialization? I don't see a >>> need to store duplicate information in new tables, and thought serializing >>> these one shot reports the best solution. >> >> I couldn't really find a good reason to store the serialized >> representation of the queries, to be honest. In fact, the only reason I >> would store the serialized representation of anything is as a last >> resort, when no other way of storing it makes sense. >> >> Going back to the methodology I covered in my previous email, I wouldn't >> store the results of a query in a database. If you find you simply must >> save the results, just jam the whole HTML page into a string and store >> that (unless I'm misunderstanding what you're doing). Otherwise, just >> generate the report in real time. > > I disagree... storing the results of a complex query that took 5 seconds > to run into a cache table that takes .01 seconds to retrieve has obvious > efficiency gains. That said, the database engine may do caching for you, > however if you know the query results are valid for a whole week, then > again it's useful to cache it yourself. Of course, the cache could also > lie on the filesystem or shared memory or whatever, but that's just > implementation details :) Either way, serialized data is quick to > generate, quick to unserialize, and since it's temporary you can use a > less flexible storage format. Perhaps, but as I said, "Going back to the methodology I covered in my previous email". The optimization you're talking about is something I'd tackle at the 2.0 version, not the first crack I encouraged him to take. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
