Reports generator

Exists any reports generator that exports directly to html/php?


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

Re: Reports generator

--=-Swz0gO7AgHkKAy3iugXm
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Tue, 2010-01-26 at 18:54 +0100, PEPITOVADECURT wrote:

> Exists any reports generator that exports directly to html/php?
>
>


What do you want to generate reports on? I would assume this would be
some sort of data from a database, and that you're looking for a
PHP-based reporting tool that can output as HTML for viewing your
reports in a web browser?

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-Swz0gO7AgHkKAy3iugXm--

Re: Reports generator

--001636e0a66e5fe850047e31d647
Content-Type: text/plain; charset=ISO-8859-1

I actually started on a report class yesterday, and I have a few questions,
but first some details:

- Reports will be on user orders (ticket reservations).
- Need to be able to build a large variety of reports based on existing data
+ Orders by a specific user
+ Orders for a specific product (event)
+ Orders by a user sub-group (organization)
+ Orders by a user super-group (school district)
- Reports need data from a primary table (orders) and several secondary
tables (users, order_lineitems, etc.)

Now, I started to approach this with a class that builds an HTML table with
the data as the end product, based upon the parameters I supply.

There shall be a table_header property which will be an array of column
names, a rows property which will be a bi-dimensional array which will
contain the data for each row.

I want to have methods like the following:


$Report->createNew('orders', 35); // STARTS AN ORDER USING `orders` TABLE -
SHOW ID 35
$Report->addColumn('contact'); // USERNAME - `users` TABLE
$Report->addColumn('phone'); // USER'S PHONE NUMBER - `users` TABLE
$Report->addColumn('quantity'); // TICKETS REQUESTED - `order_lineitems`
TABLE

// SAVE OBJECT TO `reports` TABLE
$report = serialize($Report);

$success = mysql_query('INSERT INTO `reports` (`data`) VALUES (\'' . $report
.. '\') ;');

if ($success) { $Notify->addtoQ('Report succesfully saved.', 'confirm'); }
else { $Notify->addtoQ('There was en error saving the report.', 'error'); }

?>

I was having a tough time wrapping my head around how to make the report
class less specific and more flexible. For example, I have the user's
user_id already stored in the `orders` table (of course, foreign key), but I
want to display their username (or firstname, lastname pair), which would
require another call to the `users` table, so I had a $queries property,
which would be an array of queries to execute, but then I couldn't figure
out how to handle each one, because each is handled uniquely.

So, I have to be less general, and more specific. Call what I want by
nickname, ie. $Report->addColumn('userRealName'), and have a switch
statement within the addColumn() method to check for nicknames. Whew! That
sounds awful!

And how do I handle each result in the queries array? Should I create an
associate array (ie. 'username' => 'SELECT `username` FROM `users`....',
'school' => 'SELECT `name` FROM `organization`... ') and again, have a
switch statement to determine how to handle the database result arrays?

Can anyone point me in the right direction? Should I just get down and dirty
and write a focused class (or even procedural?) for different types of
reports that I anticipate needing?


This is a tough one! Thanks!

On Wed, Jan 27, 2010 at 4:32 AM, Ashley Sheridan
wrote:

> On Tue, 2010-01-26 at 18:54 +0100, PEPITOVADECURT wrote:
>
> > Exists any reports generator that exports directly to html/php?
> >
> >
>
>
> What do you want to generate reports on? I would assume this would be
> some sort of data from a database, and that you're looking for a
> PHP-based reporting tool that can output as HTML for viewing your
> reports in a web browser?
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>

--001636e0a66e5fe850047e31d647--

Re: Reports generator

On Wed, Jan 27, 2010 at 08:20:21PM -0800, Allen McCabe wrote:

> I actually started on a report class yesterday, and I have a few questions,
> but first some details:
>
> - Reports will be on user orders (ticket reservations).
> - Need to be able to build a large variety of reports based on existing data
> + Orders by a specific user
> + Orders for a specific product (event)
> + Orders by a user sub-group (organization)
> + Orders by a user super-group (school district)
> - Reports need data from a primary table (orders) and several secondary
> tables (users, order_lineitems, etc.)
>
> Now, I started to approach this with a class that builds an HTML table with
> the data as the end product, based upon the parameters I supply.
>
> There shall be a table_header property which will be an array of column
> names, a rows property which will be a bi-dimensional array which will
> contain the data for each row.
>
> I want to have methods like the following:
>
> >
> $Report->createNew('orders', 35); // STARTS AN ORDER USING `orders` TABLE -
> SHOW ID 35
> $Report->addColumn('contact'); // USERNAME - `users` TABLE
> $Report->addColumn('phone'); // USER'S PHONE NUMBER - `users` TABLE
> $Report->addColumn('quantity'); // TICKETS REQUESTED - `order_lineitems`
> TABLE
>
> // SAVE OBJECT TO `reports` TABLE
> $report = serialize($Report);
>
> $success = mysql_query('INSERT INTO `reports` (`data`) VALUES (\'' . $report
> . '\') ;');
>
> if ($success) { $Notify->addtoQ('Report succesfully saved.', 'confirm'); }
> else { $Notify->addtoQ('There was en error saving the report.', 'error'); }
>
> ?>
>
> I was having a tough time wrapping my head around how to make the report
> class less specific and more flexible. For example, I have the user's
> user_id already stored in the `orders` table (of course, foreign key), but I
> want to display their username (or firstname, lastname pair), which would
> require another call to the `users` table, so I had a $queries property,
> which would be an array of queries to execute, but then I couldn't figure
> out how to handle each one, because each is handled uniquely.

You don't have to make a separate query; you can do a join. The problem
is how to handle it in a class/method way.

Honestly, what you're trying to do is very tricky. My suggestion is that
you do iterative development on this (I'm sure there's an erudite
programming student name for this which I don't recall). For example,
rather than doing addColumn() methods, use a rowQuery() method, and feed
that a query which will work for each row. If you like, you can allow
for "place markers" for variables, like '%ordernum%'. When you invoke
the generate() method (or whatever) have it parse the query for those
place markers, and substitute the values you supply. Then feed the query
to MySQL and capture the results in a 2D array.

Now write code which will iterate through your rows and columns and
insert them into HTML tables.

If you like, you can write a child class for each report, which inherits
from a common parent reports class. At this point, I'm not sure how much
use that would be, but you could do it.

Once you've done this and gotten it working for all your reports, you
then will have a better idea of what exact kinds of problems you're
going to run into. Then start on version 2.0, where you use that
information to build a better class with addColumn() methods, etc.

You might also consider snagging a report generation class (or somesuch)
from a place like phpclasses.org and seeing how *they* handle this.
Adapt the ideas to your needs.

I'm sorry if this doesn't help. This is just how I'd do it. The kind of
problems you're trying to solve are too abstract for my comfort, and I'd
want to get something working first which highlights the difficulties
before I tackle a full-on "pretty" OO solution.

(The other reason I'd do it this way is that I used to work for a
company that sold a report-writer coded in C. I never realized the
complexities of reports until I'd worked with that product for a while.
Subtotal levels, grand total levels, headers, footers, column labels,
gathered from a variety of COBOL, C, BASIC and other databases. Ugh.)

Paul

--
Paul M. Foster

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

Re: Reports generator

Allen, i think your primary design consideration is this;
.....
> - Need to be able to build a large variety of reports based on existing data
.....

This would lead me to jump at a 'plugin' solution.

I'd make:

- 1 superclass as interface to the rest of your webapp(s)

- 1 "top-class" that has the logic applicable to all reports.

(or just 1 top-level class, if you want)

- 1 to many plugin classes, that all use the same simple interfaces.
By using arrays as options/return-results, the whole thing becomes
extensible without breaking compatibility.

I'm working on a newsscraper (same problem basically, doing both input
to db and output from it) and for that i'm not even using classes. I'm
using plain-old functions with a specific naming convention in files,
also named according to a convention.
Some examples of plugin functions exposed in 'plugin.news.digg.php':
function plugin__news__digg__pages($mp)
function plugin__news__digg__isValidPage ($page, $pageContent)
function plugin__news__digg__parser__siteHTML ($page, $pageContent)

$mp = user-level parameters (from the superclass)
__pages returns a simple array that tells the top-class which pages to
curl (and with which parser-function (like __parser__siteHTML)),
before passing $pageContent along with $page (a conventionized
meta-data array, mostly built up by __pages) to the parser function
__parser__siteHTML.

All parser functions return an array that the top-level class can use
to insert their "hits" into the db.

Plugin functions can be called by $func =
'plugin__news__digg__parser__siteHTML'; $func ($page, $pageContent);


In your case, Allen, i'd start with plugins that accept user-level
parameters (both generic and specific in the same $options array, and
to prevent confusion through feature-creep, use more than 1 level in
the array) and then output HTML. Try to use CSS effectively.
Using the smarty library in plugins' HTML generation functions is
probably overkill, but some people like such midware.
Your top-level class can take care of any caching of finished reports.
Your superclass is responsible for building up the "frame" of the
webpage that holds the reports.
If two or more plugins need (almost) the same data, consider building
a datastore class, that sits "below" all the plugins (and the
top-class).
And i highly recommend adodb.sf.net as the db-abstraction layer, to be
used exclusively for all db access by all other classes.

On Thu, Jan 28, 2010 at 5:20 AM, Allen McCabe wrote:
> I actually started on a report class yesterday, and I have a few questions,
> but first some details:
>
> - Reports will be on user orders (ticket reservations).
> - Need to be able to build a large variety of reports based on existing data
> + Orders by a specific user
> + Orders for a specific product (event)
> + Orders by a user sub-group (organization)
> + Orders by a user super-group (school district)
> - Reports need data from a primary table (orders) and several secondary
> tables (users, order_lineitems, etc.)
>
> Now, I started to approach this with a class that builds an HTML table with
> the data as the end product, based upon the parameters I supply.
>
> There shall be a table_header property which will be an array of column
> names, a rows property which will be a bi-dimensional array which will
> contain the data for each row.
>
> I want to have methods like the following:
>
> >
> $Report->createNew('orders', 35); // STARTS AN ORDER USING `orders` TABLE -
> SHOW ID 35
> $Report->addColumn('contact'); // USERNAME - `users` TABLE
> $Report->addColumn('phone'); // USER'S PHONE NUMBER - `users` TABLE
> $Report->addColumn('quantity'); // TICKETS REQUESTED - `order_lineitems`
> TABLE
>
> // SAVE OBJECT TO `reports` TABLE
> $report = serialize($Report);
>
> $success = mysql_query('INSERT INTO `reports` (`data`) VALUES (\'' . $report
> . '\') ;');
>
> if ($success) { $Notify->addtoQ('Report succesfully saved.', 'confirm'); }
> else { $Notify->addtoQ('There was en error saving the report.', 'error'); }
>
> ?>
>
> I was having a tough time wrapping my head around how to make the report
> class less specific and more flexible. For example, I have the user's
> user_id already stored in the `orders` table (of course, foreign key), but I
> want to display their username (or firstname, lastname pair), which would
> require another call to the `users` table, so I had a $queries property,
> which would be an array of queries to execute, but then I couldn't figure
> out how to handle each one, because each is handled uniquely.
>
> So, I have to be less general, and more specific. Call what I want by
> nickname, ie. $Report->addColumn('userRealName'), and have a switch
> statement within the addColumn() method to check for nicknames. Whew! That
> sounds awful!
>
> And how do I handle each result in the queries array? Should I create an
> associate array (ie. 'username' => 'SELECT `username` FROM `users`....',
> 'school' => 'SELECT `name` FROM `organization`... ') and again, have a
> switch statement to determine how to handle the database result arrays?
>
> Can anyone point me in the right direction? Should I just get down and dirty
> and write a focused class (or even procedural?) for different types of
> reports that I anticipate needing?
>
>
> This is a tough one! Thanks!
>
> On Wed, Jan 27, 2010 at 4:32 AM, Ashley Sheridan
> wrote:
>
>> On Tue, 2010-01-26 at 18:54 +0100, PEPITOVADECURT wrote:
>>
>> > Exists any reports generator that exports directly to html/php?
>> >
>> >
>>
>>
>> What do you want to generate reports on? I would assume this would be
>> some sort of data from a database, and that you're looking for a
>> PHP-based reporting tool that can output as HTML for viewing your
>> reports in a web browser?
>>
>> Thanks,
>> Ash
>> http://www.ashleysheridan.co.uk
>>
>>
>>
>

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

Re: Reports generator

--00504502ae351b9fa1047e362f11
Content-Type: text/plain; charset=ISO-8859-1

Thanks Paul and Renee!

Paul: I am not up to par on my SQL joins, I have to get another book this
weekend; I knew that joins would be almost necessary for what I'm trying to
accomplish. Iterative development, while painstaking, seems like the hands
on approach I'm used to, and has proven effective in the past when
developing complicated procedures.

On a side note: the application I am developing is turning out to be many,
many times larger than I anticipated, and I am learning OO concepts as I go
along. Occasionally I have to rewrite code, and take the opportunity to
improve in other areas (eg. I was using 2 versions of a session management
include, and when I moved to a new improved one I made sure every page had
another new include which defined a ROOT constant*). Now and then I take a
day to move iterative code into classes.

Renee: I think your idea of a superclass (hat-tip: Paul also mentioned an
inheritance approach) and child classes is going to be necessary. Originally
I was thinking of a "handler" class (all Reports) and a singular (NOT
singleton) class (a single report), but that led me to other questions and
distracted me from productive thought.

To be fair Renee, I couldn't follow what you were saying about your
newsscraper class (I've heard of curl, but not much more than that, and what
do you mean by 'parsing'?).


My application is meant to replace faxed order forms and Excel spreadsheets
(my associate does A TON of copy/paste when dealing with seat orders). So
this needs to be flexible enough to be a viable alternative. So far it is
far superior in many respects, but in others it is lacking. Liiike printing
out an excel spreadsheet is as easy as Ctrl+P, so to achieve this end I have
to generate a report for a bare bones html page to print.

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.

Thanks again everyone!



Allen


*The include that defined a ROOT constant accomplished something I saw
someone else do, and it's genius (perhaps elementary to you experts). It is
so rudimentary I can't believe I hadn't thought of it: it searches for a
specific file "config.php" by using a while loop and the file_exists()
function, and on each iteration it adds a "../" to the file name
("../config.php" becomes "../../config.php") until it finds it (maximum of 5
levels up). Once it finds it, it assigns the "../" path to the ROOT
constant, so I can easily access my ROOT folder from anywhere in my script,
eg.

On Wed, Jan 27, 2010 at 9:57 PM, Rene Veerman wrote:

> Allen, i think your primary design consideration is this;
> ....
> > - Need to be able to build a large variety of reports based on existing
> data
> ....
>
> This would lead me to jump at a 'plugin' solution.
>
> I'd make:
>
> - 1 superclass as interface to the rest of your webapp(s)
>
> - 1 "top-class" that has the logic applicable to all reports.
>
> (or just 1 top-level class, if you want)
>
> - 1 to many plugin classes, that all use the same simple interfaces.
> By using arrays as options/return-results, the whole thing becomes
> extensible without breaking compatibility.
>
> I'm working on a newsscraper (same problem basically, doing both input
> to db and output from it) and for that i'm not even using classes. I'm
> using plain-old functions with a specific naming convention in files,
> also named according to a convention.
> Some examples of plugin functions exposed in 'plugin.news.digg.php':
> function plugin__news__digg__pages($mp)
> function plugin__news__digg__isValidPage ($page, $pageContent)
> function plugin__news__digg__parser__siteHTML ($page, $pageContent)
>
> $mp = user-level parameters (from the superclass)
> __pages returns a simple array that tells the top-class which pages to
> curl (and with which parser-function (like __parser__siteHTML)),
> before passing $pageContent along with $page (a conventionized
> meta-data array, mostly built up by __pages) to the parser function
> __parser__siteHTML.
>
> All parser functions return an array that the top-level class can use
> to insert their "hits" into the db.
>
> Plugin functions can be called by $func =
> 'plugin__news__digg__parser__siteHTML'; $func ($page, $pageContent);
>
>
> In your case, Allen, i'd start with plugins that accept user-level
> parameters (both generic and specific in the same $options array, and
> to prevent confusion through feature-creep, use more than 1 level in
> the array) and then output HTML. Try to use CSS effectively.
> Using the smarty library in plugins' HTML generation functions is
> probably overkill, but some people like such midware.
> Your top-level class can take care of any caching of finished reports.
> Your superclass is responsible for building up the "frame" of the
> webpage that holds the reports.
> If two or more plugins need (almost) the same data, consider building
> a datastore class, that sits "below" all the plugins (and the
> top-class).
> And i highly recommend adodb.sf.net as the db-abstraction layer, to be
> used exclusively for all db access by all other classes.
>
> On Thu, Jan 28, 2010 at 5:20 AM, Allen McCabe
> wrote:
> > I actually started on a report class yesterday, and I have a few
> questions,
> > but first some details:
> >
> > - Reports will be on user orders (ticket reservations).
> > - Need to be able to build a large variety of reports based on existing
> data
> > + Orders by a specific user
> > + Orders for a specific product (event)
> > + Orders by a user sub-group (organization)
> > + Orders by a user super-group (school district)
> > - Reports need data from a primary table (orders) and several secondary
> > tables (users, order_lineitems, etc.)
> >
> > Now, I started to approach this with a class that builds an HTML table
> with
> > the data as the end product, based upon the parameters I supply.
> >
> > There shall be a table_header property which will be an array of column
> > names, a rows property which will be a bi-dimensional array which will
> > contain the data for each row.
> >
> > I want to have methods like the following:
> >
> > > >
> > $Report->createNew('orders', 35); // STARTS AN ORDER USING `orders` TABLE
> -
> > SHOW ID 35
> > $Report->addColumn('contact'); // USERNAME - `users` TABLE
> > $Report->addColumn('phone'); // USER'S PHONE NUMBER - `users` TABLE
> > $Report->addColumn('quantity'); // TICKETS REQUESTED - `order_lineitems`
> > TABLE
> >
> > // SAVE OBJECT TO `reports` TABLE
> > $report = serialize($Report);
> >
> > $success = mysql_query('INSERT INTO `reports` (`data`) VALUES (\'' .
> $report
> > . '\') ;');
> >
> > if ($success) { $Notify->addtoQ('Report succesfully saved.', 'confirm');
> }
> > else { $Notify->addtoQ('There was en error saving the report.', 'error');
> }
> >
> > ?>
> >
> > I was having a tough time wrapping my head around how to make the report
> > class less specific and more flexible. For example, I have the user's
> > user_id already stored in the `orders` table (of course, foreign key),
> but I
> > want to display their username (or firstname, lastname pair), which would
> > require another call to the `users` table, so I had a $queries property,
> > which would be an array of queries to execute, but then I couldn't figure
> > out how to handle each one, because each is handled uniquely.
> >
> > So, I have to be less general, and more specific. Call what I want by
> > nickname, ie. $Report->addColumn('userRealName'), and have a switch
> > statement within the addColumn() method to check for nicknames. Whew!
> That
> > sounds awful!
> >
> > And how do I handle each result in the queries array? Should I create an
> > associate array (ie. 'username' => 'SELECT `username` FROM `users`....',
> > 'school' => 'SELECT `name` FROM `organization`... ') and again, have a
> > switch statement to determine how to handle the database result arrays?
> >
> > Can anyone point me in the right direction? Should I just get down and
> dirty
> > and write a focused class (or even procedural?) for different types of
> > reports that I anticipate needing?
> >
> >
> > This is a tough one! Thanks!
> >
> > On Wed, Jan 27, 2010 at 4:32 AM, Ashley Sheridan
> > wrote:
> >
> >> On Tue, 2010-01-26 at 18:54 +0100, PEPITOVADECURT wrote:
> >>
> >> > Exists any reports generator that exports directly to html/php?
> >> >
> >> >
> >>
> >>
> >> What do you want to generate reports on? I would assume this would be
> >> some sort of data from a database, and that you're looking for a
> >> PHP-based reporting tool that can output as HTML for viewing your
> >> reports in a web browser?
> >>
> >> Thanks,
> >> Ash
> >> http://www.ashleysheridan.co.uk
> >>
> >>
> >>
> >
>

--00504502ae351b9fa1047e362f11--

Re: Reports generator

On 26 January 2010 17:54, PEPITOVADECURT wrote:
> Exists any reports generator that exports directly to html/php?

Depending upon your platform, you have the option of using an external
report generator and invoking it appropriately from within PHP.

I'm on Windows and use Crystal Reports via PHP support of COM.

I then output the reports to MS Word, MS Excel, HTML or PDF -
depending upon the report/requirement/etc.

Due to the interface provided by Crystal, you can create an entire
report programmatically. It is a LOT of work, but it can be done.



--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

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

Re: Reports generator

It's Rene, not Renee :p

curl is a method of fetching http pages from within php (and other languages).

with parsing i meant "parse(process) a html page into (in my case) an
array of "hits" found on that page".

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

Re: Reports generator

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.

Paul

--
Paul M. Foster

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

Re: Reports generator

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.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

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

Re: Reports generator

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.

Paul

--
Paul M. Foster

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

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

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