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 M. Foster

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

Reply via email to