Re: Reports generator

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: <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.

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. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP