Paul M Foster wrote:
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:


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.

I don't believe in arduous investment in early optimization but if it's low hanging fruit and you're already aware of the issue, programming it in early can save you time later.

Application and Templating Framework for PHP

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to